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PREFACE 


Program  Methodology  is  the  second  volume  in  the  three-volume  IMIS  Final  Program 
Report.  The  IMIS  program  was  conducted  in  three  phases:  Requirements  Analysis;  System 
Design  and  Development;  and  Demonstration  System  Fabrication  and  Field  Evaluation.  Main 
objectives  of  the  Requirements  Analysis  phase  were  to:  (1)  identify  and  analyze  the  functional, 
informational,  and  human-computer  interface  requirements  for  an  IMIS  in  the  Air  Force 
maintenance  environment;  (2)  develop  a  system  architecture  which  supported  those 
requirements;  and  (3)  develop  system  functional  requirements  specifications.  Primary  products 
of  the  Requirements  Analysis  were  the  IMIS  Architecture  and  the  System/Segment  Specification. 
During  System  Design  and  Development,  a  subset  of  IMIS  requirements  was  selected  for 
implementation  and  demonstration.  Upon  completion  of  the  IMIS  demonstration  system, 
hardware  and  software  were  installed  and  field  tested  at  Luke  Air  Force  Base,  Arizona' 
Objectives  of  the  field  evaluation  were  to:  (1)  test  the  IMIS  concept  under  realistic  operational 
conditions,  (2)  evaluate  IMIS  effectiveness  in  supporting  the  unit  maintenance  mission,  (3) 
demonstrate  the  technical  advantages  of  IMIS  over  the  current  system,  and  (4)  identify  strengths 
and  weaknesses  of  the  demonstration  system  which  could  be  used  in  refining  requirements  for  a 
production  implementation. 


INTEGRATED  MAINTENANCE  INFORMATION  SYSTEM  (IMIS) 
PROGRAM  METHODOLOGY 


INTRODUCTION 

The  Air  Force  has  developed  and  is  continuing  to  develop  several  computer  systems  to 
support  organizational-level  (0-Level)  maintenance.  Unless  planned  integration  occurs,  the  Air 
Force  of  the  future  will  have  multiple  computer  systems  in  use  simultaneously,  causing 
confusion  as  a  result  of  incompatible  hardware,  data  requirements,  user  interfaces,  and  expertise 
required  to  operate  and  maintain  the  systems.  These  deficiencies  can  cause  improper  weapon 
system  maintenance,  potentially  leading  to  weapon  system  malfunctions,  equipment  damage  or 
loss,  or  personnel  injury.  This  degradation  in  weapon  system  and  unit  readiness  limits  the  ability 
of  combat  organizations  to  accomplish  their  assigned  missions. 

The  Integrated  Maintenance  Information  System  (IMIS)  is  a  proof  of  concept  program  to 
integrate  all  maintenance  information.  It  is  the  tool  to  access,  from  all  available  sources, 
information  required  to  support  maintenance,  then  integrate,  format,  and  present  that  data  for  use 
by  maintenance  personnel.  By  integrating  the  information  from  the  maintenance  support  systems 
currently  in  use  and  providing  a  standard  mechanism  for  accessing  and  presenting  that 
information,  IMIS  can  eliminate  the  need  for  maintenance  personnel  to  learn  the  unique 
operations  of  and  interact  with  multiple  systems. 

Background 

Since  1976,  the  Armstrong  Laboratory  Logistics  Research  Division  (AL/HRG)  has 
conducted  several  research  and  development  (R&D)  projects  to  develop  the  technology  for  the 
presentation  of  technical  data  on  an  automated  system.  From  1976  through  1988,  these  efforts 
included  two  feasibility  studies,  the  development  of  two  prototype  systems  to  support 
intermediate-level  (I-Level)  maintenance,  and  the  development  of  a  portable  computer  system  for 
presentation  of  technical  data  for  on-equipment  maintenance.  The  scope  of  these  efforts 
involved  performing  laboratory  studies  to  develop  the  required  technologies,  as  well  as  testing 
the  prototype  systems  under  realistic  field  conditions  to  ensure  the  systems  satisfactorily  met  the 
needs  of  the  users. 

AL/HRG’ s  efforts  demonstrated  that  the  presentation  of  maintenance  technical  data  on  a 
computer-based  system  was  feasible  and  that  an  automated  system  had  the  potential  to  improve 
performance  and  reduce  the  costs  of  maintaining  the  Air  Force  technical  order  (TO)  system.  In 
addition,  effective  user  interface  (UI)  techniques,  data  presentation  techniques,  and  draft 
specifications  for  computer  hardware  and  software  were  developed. 

In  addition  to  demonstrating  the  benefits  of  an  automated  data  presentation  system,  these 
studies  also  pointed  out  the  need  for  a  more  comprehensive  system  to  make  maintenance 
information  available  to  Air  Force  maintenance  personnel,  not  just  the  technician.  The  lessons 


1 


learned  from  these  efforts  played  a  major  role  in  developing  the  IMIS  Operational  Concept 
Document  (OCD),  which  formed  the  basis  of  the  IMIS  program. 

Scope 

The  overall  scope  of  the  IMIS  program  involved  several  different  thrusts:  to  identify  and 
define  the  requirements  for  an  IMIS;  to  develop  specifications  which  document  those 
requirements;  to  design  and  develop  a  demonstration  system  capable  of  supporting  the  essential 
IMIS  requirements;  to  evaluate  the  IMIS  concept  and  requirements  using  the  demonstration 
system;  and  to  finalize  the  IMIS  specifications,  incorporating  the  results  of  the  tests, 
demonstrations,  and  evaluations  conducted.  The  structure  of  the  program  was  intended  to  satisfy 
each  of  these  major  thrusts,  as  well  as  to  allow  maximum  application  of  information  gained 
during  each  phase  to  subsequent  phases. 


Purpose 

The  objective  of  the  IMIS  system  was  to  improve  the  capabilities  of  aircraft  (A/C) 
maintenance  organizations  by  providing  Air  Force  personnel  an  effective  maintenance 
information  system.  The  improved  information  system  would  increase  the  performance 
capabilities  of  the  maintenance  personnel,  resulting  in  an  increased  sortie  generation  capability. 
Specific  objectives  for  IMIS  were  identified  in  the  OCD.  These  objectives  are  as  follows. 

a.  Integrate  multiple  maintenance  information  sources  into  a  single  easy-to-use  information 
system. 

b.  Tailor  information  to  meet  the  specific  needs  of  the  task  and  the  technician. 

c.  Provide  on-the-job  training  aid  for  new  systems  and  proficiency  training  on  existing 
systems. 

d.  Eliminate  time-consuming  paperwork  and  tasks  through  automation. 

e.  Improve  on-A/C  diagnostics  and  reduce  “Can  Not  Duplicates”  (CNDs)  and  “Retest  OKs” 
(RTOKs). 

f.  Improve  the  quality  of  maintenance  performance  by  taking  advantage  of  the  computer’s 
ability  to  interact  with  the  technician. 

g.  Maximize  the  utilization  of  available  manpower  resources  by  providing  information  in 
standard,  generic  formats  independent  of  the  subsystem  and  supporting  general  technical 
capabilities  at  various  skill  levels. 

h.  Improve  the  maintenance  capability  for  dispersed  operations  by  packaging  the  needed 
maintenance  information  into  a  highly  portable,  deployable  system. 
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i.  Provide  the  capability  to  support  maintenance  performance  in  future  scenarios  of 
consolidated  specialties. 

Although  many  of  these  objectives  focus  on  the  maintenance  technician,  the  goal  of  IMIS 
is  to  enhance  the  performance  of  all  maintenance  persoimel,  regardless  of  their  role  in  the 
maintenance  process.  By  allowing  easy  access  to  current  maintenance  information,  IMIS  would 
enable  all  maintenance  personnel,  including  technicians,  managers,  and  support  personnel,  to 
make  more  informed  decisions,  thereby  improving  the  maintenance  process  and  increasing  the 
availability  and  mission  readiness  of  the  weapon  systems. 

Content  of  Final  Program  Report 

This  Final  Program  Report  consists  of  three  volumes.  Volume  1,  the  Executive 
Summary,  contains  a  high-level  summary  of  the  objectives,  methodology,  results,  conclusions, 
and  recommendations  of  the  entire  program.  Volume  2  provides  an  overview  of  the 
methodology  used  to  satisfy  the  objectives  of  the  IMIS  program.  This  includes  information  on 
the  requirements  analysis  conducted  in  Phases  I  and  II,  the  hardware  and  software  design 
activities  in  Phases  II  and  III,  and  the  system  integration  and  field  test  activities  of  Phase  III. 
Volume  3  contains  the  results  and  conclusions  of  each  of  the  field  tests  conducted  at  Luke  Air 
Force  Base  (AFB),  along  with  recommendations  based  on  lessons  learned  from  all  phases  of  the 
program.  It  also  discusses  strategies  for  further  implementation  of  an  IMIS  system. 


PROGRAM  OVERVIEW 

The  IMIS  program  was  conducted  in  three  phases,  beginning  in  November  1988.  The 
following  sections  provide  an  overview  of  the  organizations  involved  in  the  program  and  their 
responsibilities,  as  well  as  a  high-level  schedule  and  description  of  the  three  program  phases. 

Program  Team  Organization  and  Responsibilities 

AL/HRG,  the  Logistics  Research  Division  of  Armstrong  Laboratory  at  Wright-Patterson 
AFB,  was  the  program  customer.  As  the  customer,  AL/HRG  was  involved  in  all  aspects  of  the 
program  and  oversaw  the  design  and  development  of  the  system  through  the  review  of  the 
appropriate  documentation  and  design  review  materials,  as  well  as  by  conducting  additional 
integration  testing.  AL/HRG  also  was  responsible  for  planning  and  conducting  each  field  test. 

GDE  Systems,  Inc.,  in  San  Diego,  California  (formerly  General  Dynamics  Electronics 
Division),  the  prime  contractor,  had  overall  responsibility  for  managing  program  activities.  GDE 
Systems  was  responsible  for  the  hardware  and  software  development,  as  well  as  system 
integration  and  test  prior  to  the  field  tests.  GDE  Systems  also  supported  the  field  tests  by 
providing  personnel  as  members  of  the  evaluation  teams  and  to  perform  system  support  and 
maintenance. 
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Softech,  Inc.,  in  Dayton,  Ohio,  was  a  subcontractor  to  GDE  Systems  in  the  early  stages  of 
the  program.  Softech  assisted  in  base  visits,  requirements  analysis  for  the  IMIS  Architecture 
(IMISA),  and  generation  of  the  preliminary  system  and  software  specifications. 

Systems  Control  Technology,  Inc.  (SCT),  in  Palo  Alto,  California,  was  a  subcontractor  to 
GDE  Systems  during  the  design  and  implementation  phases  of  the  program.  SCT  developed  the 
interface  to  the  Core  Automated  Maintenance  System  (CAMS)  and  assisted  with  integrating  that 
software  into  the  IMIS  system  prior  to  demonstration. 


Applied  Science  Associates,  Inc.  (ASA),  in  Butler,  Pennsylvania,  was  a  subcontractor  to 
GDE  Systems.  ASA  assisted  in  base  visits,  participated  in  the  development  of  the  human 
engineering  requirements,  and  reviewed  the  human  engineering  aspects  of  the  system  design  and 
development.  ASA  also  assisted  in  the  development  and  administration  of  the  training  program, 
as  well  as  the  planning  and  execution  of  the  field  tests. 

Lockheed  Fort  Worth  Company  (LFWC)  of  Fort  Worth,  Texas  (formerly  General 
Dynamics  Fort  Worth  Division),  had  a  separate  contract  with  the  F-16  System  Program  Office 
(SPO)  to  provide  software  for  authoring  and  presenting  electronic  TO  data,  and  to  author  the  TO 
data  for  five  F-16  subsystems  in  support  of  the  IMIS  contract. 

NCI  Information  Systems,  Inc.  (NCI),  in  Dayton,  Ohio,  was  a  contractor  to  AL/HRG. 
NCI  enhanced  the  electronic  TO  data  developed  by  LFWC  and  maintained  that  data  throughout 
the  field  tests.  NCI  also  provided  maintenance  and  diagnostics  expertise  in  their  participation  in 
the  field  tests. 


Program  Schedule 

The  IMIS  program  was  conducted  in  three  phases:  Requirements  Analysis,  System 
Design  and  Development,  and  Demonstration  System  Fabrication  and  Field  Evaluation.  Figure  1 
shows  a  high-level  schedule  for  each  phase,  including  significant  milestones.  Figure  2  shows  the 
key  IMIS  activities  and  products  of  those  activities  in  the  three  phases.  The  following  sections 
discuss  the  tasks  performed  in  each  phase. 

Phase  I:  Requirements  Analysis 

The  main  objectives  of  the  Requirements  Analysis  phase  were:  to  identify  and  analyze 
the  functional,  informational,  and  human-computer  interface  requirements  for  an  IMIS  in  the  Air 
Force  maintenance  environment;  to  develop  a  system  architecture  which  supported  those 
requirements;  and  to  develop  system  functional  requirements  specifications.  One  critical  task  in 
support  of  the  requirements  analysis  was  to  interview  maintenance  personnel  at  several  bases. 

The  primary  products  of  Phase  I  were  the  IMISA,  developed  using  a  structured  analysis 
methodology,  and  the  System/Segment  Specification  (SSS),  which  documents  the  IMIS  system 
requirements.  This  information  was  reviewed  at  the  System  Requirements  Review  at  the  end  of 
Phase  I. 
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S  Program  Schedule 


ACTIVITIES 


OCD 

STATEMENT  OF  WORK 


PRODUCT 


PHASE  I:  REQUIREMENTS  ANALYSIS 


•  Research 

•  Maintenance  Scenario  Reviews 

•  Base  Visits 

•  Maintenance  Personnel  Interviews 

•  Integrated  Computer-Aided  Manufacturing 

(ICAM)  Definition  (IDEF)  Models 

•  Design  Requirements  Reviews 


SYSTEMS  ENGINEERING  ANALYSIS  (SEA) 
REPORT 

HUMAN  ENGINEERING  SYSTEM  ANALYSIS 
W  I _ REPORT  (HESAR) _ 

PHASE  II:  DESIGN  &  DEVELOPMENT  REQUIREMENTS  ^ 


•  Capabilities  Assessment  Review  / 

•  Focus  on  Demonstration  vs.  Full-up  IMIS  / 

•  Working  Groups  / 

•  Design  Reviews  / 

•  Validation  of  Maintenance  Scenarios 

•  User  Interface 

•  Breadboard  Hardware  y 

•  Lessons  Learned/Update  Design  &  Documents  \ 


PHASE  III:  DEMONSTRATION  SYSTEM  FABRICATION 


♦  Fabrication  of  Brassboard  Hardware 

•  Increase  functionality  of  Software 

♦  Critical  Design  Review 

•  Lessons  Learned/Update  Design  &  Documents 


•  Fabrication  of  Demonstration  Hardware 

•  System  Integration  &  Test 


PHASE  III:  FIELD  DEMONSTRATION  &  EVALUATION 


•  Installation  at  Luke  Air  Force  Base  (AFB) 

•  Training  for  Users  &  Evaluation  Team 

•  Lessons  Learned/Update  Specifications 
.  •  Installation  at  AL/HRGO 


INTERFACE 

REQUIREMENTS 

SPECIFICATION 

(IRS) 


PRIME  ITEM  DEVELOPMENT 
SPECIFICATIONS  (PIDS) 

PRIME  ITEM  PRODUCT 
FABRICATION 
SPECIFICATIONS  (PIPFS) 


SOFTWARE  DESIGN 
DOCUMENT  (SDD) 

SOFTWARE  PRODUCT 
SPECIFICATION 


INTERFACE  DESIGN 
DOCUMENT  (IDD) 


FIELD  TEST  AND 
DEMONSTRATION 
(DEMO)  PLAN 


CONTRACTOR  TEST  PLAN 


SOFTWARE  TEST  PLAN 


Test  &  Demonstration  ' 
of  Breadboard  System 


Test  &  Demonstration 
of  Brassboard  System 


Functionality  Review  of 
Demonstration  Hardware, 
Software 


Debrief  Test 

End-to-End  Demonstration 
Fault  Isolation  Test 


- - - - - - — - - — ^  FINAL  PROGRAM  REPORT-*^ 

Figure  2.  IMIS  Phases  I  -  III  Key  Activities  and  Products 
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LESSONS  LEARNED/FINDINGS 


Phase  11:  System  Design  and  Development 

After  the  desired  IMIS  capabilities  of  a  full  implementation  were  defined,  the  program 
activities  shifted  to  the  development  of  the  demonstration  system.  During  this  phase,  a  subset  of 
the  IMIS  requirements  was  selected  for  implementation  and  demonstration.  Following  the 
successful  completion  of  the  System  Design  Review  and  the  Preliminary  Design  Review,  efforts 
were  concentrated  on  developing  a  breadboard  system  for  demonstration  at  the  Interim  Design 
Review.  The  Interim  Design  Review  and  Breadboard  Demonstration  marked  the  end  of  Phase  II. 

Phase  III:  Demonstration  System  Fabrication  and  Field  Evaluation 

The  main  objective  early  in  Phase  III  was  the  fabrication  and  testing  of  a  brassboard 
system  for  demonstration  at  the  Critical  Design  Review  (CDR).  Based  on  lessons  learned  from 
the  Breadboard  and  Brassboard  demonstrations,  the  final  software  and  hardware  designs  for  the 
demonstration  system  were  approved.  The  demonstration  hardware  and  software  were 
developed  in  accordance  with  these  approved  designs.  Extensive  system  integration  and  testing 
were  conducted  in  preparation  for  the  field  tests.  Additionally,  plans  for  conducting  the  field 
evaluations  and  for  training  personnel  to  support  the  field  tests  were  developed. 

After  the  installation,  integration,  and  testing  of  the  demonstration  system  was  completed, 
three  field  tests  were  conducted:  the  Debrief  Test,  the  End-to-End  Demonstration,  and  the  Fault 
Isolation  Test.  Results  of  these  tests  and  of  the  entire  program  were  discussed  at  the  Final 
Program  Review  and  are  documented  in  this  Final  Program  Report. 


REQUIREMENTS  ANALYSIS 

It  is  critical  on  any  program  to  identify  clearly  the  requirements  as  early  as  possible.  For 
IMIS,  this  process  began  with  the  analysis  and  modeling  of  the  maintenance  environment  and 
continued  with  a  structured  methodology  for  defining  the  resulting  architecture.  Once  the 
complete  set  of  requirements  for  a  full  implementation  of  an  IMIS  system  had  been  developed, 
the  process  of  selecting  specific  requirements  to  be  implemented  in  the  demonstration  system 
was  initiated.  This  section  documents  the  comprehensive  requirements  analysis  methodology 
which  was  used  to  define  the  IMIS  demonstration  requirements  and  to  determine  the  architecture 
which  satisfies  those  requirements. 

Maintenance  Process  Analysis 

A  structured,  comprehensive  analysis  of  the  maintenance  process  was  necessary  for  the 
IMIS  system  to  be  acceptable  to  the  maintenance  user  and  to  provide  the  Air  Force  with  accurate 
information  regarding  the  benefits  of  the  IMIS  concept.  The  early  direct  involvement  with  and 
feedback  from  the  ultimate  users  of  the  system,  accomplished  through  extensive  interviews 
conducted  at  various  AFBs,  was  key  to  enhancing  the  usability  and  the  user’s  acceptance  of  the 
system.  By  supplementing  the  information  gathered  from  interviews  with  a  structured 
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methodology  for  modeling  the  maintenance  environment,  the  maintenance  process  analysis  was 
further  improved.  The  following  subsections  describe  the  details  of  the  process  and  the  analysis. 

Base  Visits 

The  objective  of  the  base  visits  was  to  interview  a  large  number  of  maintenance  personnel 
who  perform  a  wide  range  of  duties  and  functions  within  the  maintenance  environment.  Data 
gathered  during  these  interviews  was  used  to  support  the  modeling  of  the  maintenance 
environment  and  the  definition  of  requirements  for  the  system  architecture.  From  this  in-depth 
understanding  of  the  existing  maintenance  environment,  including  its  strengths  and  weaknesses, 
IMIS  was  designed  to  maximize  system  effectiveness  and  user  acceptance.  Experience  has 
shown  that  no  single  person  possesses  full  knowledge  of  the  entire  maintenance  process  in 
accurate  detail.  By  interviewing  many  maintenance  personnel  at  several  bases,  a  better 
understanding  of  the  process  and  its  requirements  was  gained.  More  than  400  maintenance 
personnel,  covering  29  different  Air  Force  Specialty  Codes  (AFSCs)  and  numerous  duty  ftles, 
were  interviewed  at  the  following  Tactical  Air  Command  (TAC)  and  United  States  Air  Forces 
Europe  (USAFE)  bases  in  1989; 

Langley  AFB,  VA 
Homestead  AFB,  FL 

Hahn  Air  Base  (AB),  Federal  Republic  of  Germany  (FRG) 

Spangdahlem  AB,  FRG 
Sembaeh  AB,  FRG 
Leipheim  AB,  FRG 
Ramstein  AB,  FRG 
Moody  AFB,  GA 
Shaw  AFB,  SC 

In  addition,  interviews  were  also  conducted  at  Gunter  AFB  (the  Standard  Systems  Center 
[SSC]  at  Gunter  is  responsible  for  the  development  and  maintenance  of  CAMS  and  the  Standard 
Base  Supply  System  [SBSS]).  Through  extensive  interacfon  with  CAMS  and  SBSS  personnel, 
the  IMIS  team  obtained  interface  information  and  other  technical  data  for  each  of  these 
maintenance  support  systems. 


Interviews  with  the  A/C  maintenance  personnel  were  voluntary  and  anonymous.  They 
were  conducted  in  accordance  with  paragraph  30  of  Air  Force  Regulafon  (AFR)  12-35  and  in 
compliance  with  the  Privacy  Act  of  1974.  As  an  aid  in  gathering  and  categorizing  information,  a 
strawman  model  was  developed  to  describe  the  maintenance  tasks  performed  by  these  personnel 
between  the  end  of  one  mission  and  the  beginning  of  the  next.  The  activities  described  in  this 
model,  derived  from  Air  Combat  Command  (ACC)  Regulation  66-5  and  coordinated  with 
subject  matter  experts  from  the  maintenance  community,  included:  obtain  A/C  status,  allocate 
resources,  troubleshoot  A/C,  order  parts,  repair  A/C,  and  perform  standard  service. 

The  questionnaires  used  in  these  interviews  were  designed  to  extract  data  from 
maintenance  personnel  in  a  manner  that  would  lend  itself  to  the  subsequent  modeling  process. 
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The  questionnaires  covered  all  aspects  of  the  six  activities  described  in  the  strawman  model.  For 
each  activity,  the  technician  was  asked  to  describe  the  tasks  performed,  the  sequencing  and 
dependencies  of  these  tasks,  how  the  tasks  are  initiated  and  completed,  the  results  of  the  tasks, 
data  needed  to  perform  the  task,  and  how  that  data  is  accessed  or  provided. 

Maintenance  Environment  Modeling  Methodology 

The  information  collected  during  the  data  gathering  interviews  was  analyzed  and  used  to 
model  the  maintenance  process.  Figure  3  shows  the  collected  data  was  used  as  a  direct  input  to 
the  model.  Audio  tapes  of  the  interviews  were  used  to  augment  the  data  collected  via  notes.  Air 
Force  forms  and  other  materials  which  identified  the  data  requirements  for  the  maintenance 
process  were  also  used  to  develop  the  model. 


RECORDED 

INTERVIEW 


INTERVIEWS 
WITH  VARIOUS! 
MAINTENANCE^ 
PERSONNEL 


-  -  1 

-  NOTES 

- '  PROCEDURE  SORTED/ 

KEY  POINTS/  DESCRIPTION,  ANALYZED 

SUMMARIZATIONS  ACTIVITIES  AND  INFORMATION 

INFORMATION 

DEFINITION  FOR 

FORMS  CURRENTLY 
USED  IN  MAINTENANCE 
OPERATION 

EACH  INTERVIEWEE 

INFORMATION 

GUIDES 

MODEL 


Figure  3.  Maintenance  Environment  Modeling  Methodology 

This  database  of  information  was  then  used  to  develop  the  model  of  the  existing 
maintenance  environment.  Although  this  process  was  straightforward,  it  was  not  just  a 
reorganization  of  the  data  in  the  database  into  a  graphic  form.  The  process  of  developing  a 
model  from  raw  data  requires  the  introduction  of  engineering  knowledge  because  the  data  is 
usually  based  on  an  “organizational”  look  of  a  given  process,  not  a  “functional”  look.  However, 
the  organizational  look  is  required  to  allow  the  model  to  be  validated  by  the  user. 

The  first  step  of  the  modeling  activity  was  to  define  the  purpose  and  viewpoint  of  the 
model.  The  purpose  of  this  model  is  to  provide  a  means  of  logically  illustrating,  documenting, 
and  communicating  the  functional  activities  and  informational  relationships  associated  with  the 
maintenance  performed  on  an  A/C.  The  viewpoint  of  the  model  was  defined  to  be  the  O-Level, 
1-Level,  and  depot-level  maintenance  personnel  and  staff  personnel. 
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The  top-level  model  was  developed,  taking  the  purpose  and  viewpoint  into  account.  The 
top  level  model  comprised  maintenance  that  is  performed  at  the  0-Level,  I-Level,  and  depot 
level.  The  primary  emphasis  was  on  the  O-Level,  which  focuses  on  performing  maintenance  on 
the  flight  line.  However,  there  were  interfaces  between  the  O-Level  and  I-Level  critical  to  the 
maintenance  process  that  needed  to  be  identified.  Also  included  were  base-level  management 
functions  performed  by  personnel  on  the  staff  for  the  Deputy  Commander  for  Maintenance 
(DCM).  As  a  result,  this  model  includes  decompositions  of  the  O-Level,  I-Level,  and  staff 
functions. 

Extensive  verification  and  validation  of  the  model  were  performed,  including  internal 
verification  by  different  organizations  with  varied  experience  and  backgrounds  in  maintenance, 
as  well  as  validation  with  the  user.  The  validation  of  the  model  with  the  user  achieved  two 
important  objectives:  to  develop  a  more  accurate  model,  and  to  elicit  user  input  and  contributions 
to  the  modeling  effort.  The  models  were  presented  to  several  functional  work  groups,  each 
consisting  of  maintenance  personnel  with  the  same  job  title.  Any  discrepancies  identified  during 
the  validation  were  used  to  update  the  model. 

IMIS  Architecture  Definition 

The  methodology  described  in  the  previous  paragraph  to  model  the  existing  maintenance 
environment  used  a  structured  analysis  method  based  on  Integrated  Computer-Aided 
Manufacturing  (ICAM)  Definition  (IDEE),  a  methodology  that  is  used  to  model  system  planning, 
requirements  analysis,  and  system  design.  This  methodology,  and  all  the  models  developed 
using  this  methodology,  is  described  in  the  following  subsections,  to  show  how  the  IMISA  was 
defined. 

IDEE  Methodology 

The  IMIS  IDEE  models  consist  of  a  set  of  related  diagrams  which  are  organized  in  a  top- 
down  manner  and  are  representative  of  the  tactical  A/C  maintenance  environment.  Transferring 
user  needs  into  system  requirements  cannot  be  done  in  a  single-step  process.  Consequently,  a 
framework  for  organizing  various  viewpoints  needed  to  develop  the  IMISA  and  its  requirements 
was  used.  The  Control  Architecture  (CA)  is  a  process-versus-information  (activity)  model  that 
describes  the  user’s  view  of  the  maintenance  environment  and  the  user’s  information  needs.  The 
Information  Architecture  (lA)  is  a  data  model  which  reorganizes  the  information  derived  from 
the  CA  Model  into  logical  structures.  The  Computer  Systems  Architecture  (CSA)  takes  the 
information-processing  requirements  defined  in  the  lA  and  the  information-handling 
requirements  defined  in  the  CA  and,  by  relating  them  to  a  set  of  system  processes,  defines  system 
requirements  such  as  storage  type,  storage  size,  display  type,  user  interfaces,  and  other  hardware 
and  software  requirements.  Relative  to  the  A/C  maintenance  environment,  the  CA  defines  the 
maintenance  functions,  the  I A  defines  the  information  relationships,  and  the  CSA  defines  the 
information-handling  requirements  of  the  maintenance  process. 

The  modeling  process  described  starts  with  the  user  in  the  “AS-IS”  world.  The  “AS-IS” 
world  is  represented  by  the  existing  Air  Eorce  maintenance  procedures  as  determined  by  the  on- 
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site  interviews  and  data  collection  processes.  The  resulting  requirements  are  those  for  a  system 
that  works  in  the  current  maintenance  environment.  The  maintenance  model,  described  in  the 
subsection  entitled  “Maintenance  Environment  Modeling  Methodology,”  is  actually  the  CA  “AS- 
IS”  model.  To  take  on  the  problem  of  resolving  “AS-IS”  versus  “TO-BE”  requirements  with 
available  data,  a  threaded  modeling  approach  was  used.  In  this  approach,  the  designer  alternately 
uses  both  the  “AS-IS”  models  and  the  “TO-BE”  models  to  derive  the  IMISA.  A  set  of  projected 
assumptions  was  derived  that  was  used  to  extrapolate  the  CA  “AS-IS”  model  into  a  CA  “TO- 
BE”  model.  The  corresponding  lA  and  CSA  “TO-BE”  models  were  developed  using  the  same 
systematic  approach  that  was  used  to  build  the  “AS-IS”  set. 

IMIS  Architecture  (IMISA) 

After  all  the  modeling  activities  had  been  completed,  the  comprehensive  requirements  for 
an  IMISA  that  represents  both  the  present  and  future  functional  characteristics  were  documented 
in  the  IMISA,  Contract  Data  Requirements  List  (CDRL)  13.  The  IMISA  consists  of  the  IMIS 
architectural  requirements  based  on  the  analyses  and  results  of  the  base  visits,  interviews, 
maintenance  scenarios,  maintenance  task  timelines,  and  modeling  efforts.  This  document 
contains  complete  documentation  of  the  IDEF  modeling  guidelines,  the  interview  materials  for 
the  data  gathering  trips,  and  information  from  each  of  the  six  models  (CA  “AS-IS,”  lA  “AS-IS,” 
CSA  “AS-IS,”  CA  “TO-BE,”  lA  “TO-BE,”  and  CSA  “TO-BE”). 

System/Segment  Specification  (SSS) 

The  SSS,  CDRL  14,  establishes  the  system  definition,  performance,  design,  development, 
and  test  requirements  for  a  full  implementation  of  an  IMIS.  Requirements  in  the  SSS  were 
derived  primarily  from  the  interviews  conducted  with  maintenance  technicians  and  managers  in 
developing  the  IMISA.  Additional  sources  included  the  IMIS  OCD,  the  Advanced  Tactical 
Fighter  (ATF)  Integrated  Maintenance  System  (AIMS)  Concept  Document,  the  Modular 
Avionics  Systems  Architecture  (MASA)  Support  Requirements  Document,  and  information  from 
previous  Air  Force  projects. 

The  requirements  listed  in  the  SSS  are  directly  traceable  to  these  sources.  Requirements 
derived  from  the  models  trace  to  actual  interviews.  This  traceability  is  essential  to  the  evolution 
of  IMIS  in  that,  as  changes  and  improvements  are  discussed,  the  models  and  underlying 
interviews  can  provide  an  understanding  of  their  possible  impacts  on  the  overall  maintenance 
process. 

The  SSS  has  been  updated  throughout  the  life  of  the  IMIS  program  to  reflect  changes  to 
the  Air  Force  organization,  changes  to  the  maintenance  environment,  and  lessons  learned  during 
the  design,  development,  and  evaluation  of  the  demonstration  IMIS. 

Systems  Engineering  Analysis  (SEA)  Report 

During  Phase  II,  several  systems  engineering  analyses  were  conducted  to  identify  and 
evaluate  the  baseline  characteristics,  requirements,  and  constraints  of  a  system  which  meets  the 
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functional  requirements  specified  in  the  IMIS  OCD,  the  IMISA,  and  the  SSS.  The  results  of 
these  analyses  are  summarized  in  the  following  subsections.  Detailed  results  are  documented  in 
the  SEA  Report,  CDRL  19. 

Survivability A^ulnerability  Study 

The  Survivability/Vulnerability  Study  identified  the  threat  environment  for  Maintenance 
Data  Base  (MDB)  interfaces  and  for  an  IMIS-internal  Local  Area  Network  (LAN).  The  threats 
analyzed  include  non-nuclear  threats  (such  as  conventional  arms,  electronic  warfare,  directed 
energy,  jamming,  and  chemical^iological  substances)  and  nuclear  threat  effects  (such  as 
electromagnetic  pulse,  radiation,  and  shock).  These  threats  were  analyzed  by  tailoring  the  Data 
Link  Vulnerability  Assessment  (DVAL)  and  Network  Communications  Vulnerability 
Assessment  (NCVA)  methodologies  specifically  to  the  IMIS  system. 

Various  network  designs  were  evaluated  against  the  physical  destruction  threat,  and  it 
was  found  that  redundancy  of  communication  links  and  workstations  will  allow  increased 
survival  probabilities  in  the  event  of  an  attack. 

The  greatest  nuclear  threat  was  determined  to  be  from  the  high-altitude  electromagnetic 
pulse  (HEMP)  effect.  Nuclear  detonations  at  high  altitudes  as  far  away  as  several  thousand  miles 
will  generate  electromagnetic  pulses  which  can  induce  large  currents  in  power  lines,  signal  lines, 
radio  frequency  (RF)  antennas,  and  grounding  systems.  This  can  damage  electrical  and 
electronic  components;  microprocessor-based  equipment  is  particularly  vulnerable  to  damage. 

A  significant,  specific  threat  from  biological,  chemical,  and  directed  energy  (e.g.,  lasers) 
weapons  was  not  considered  to  be  feasible  for  a  support  system  such  as  IMIS. 

Hardware  Technology  Studies 

Five  trade  studies  were  performed  to  investigate  alternative  technologies  and  designs  for 
various  components  of  IMIS.  These  trade  studies  evaluated  batteries,  mass  storage  devices, 
displays,  and  microprocessors  for  the  Portable  Maintenance  Aid  (PMA),  as  well  as  an 
investigation  into  the  configuration  for  an  aircraft-mounted  Aircraft  Interface  Panel  (AIP). 

PMA  Battery  Study.  The  PMA  battery  study  identified  the  characteristics  desired  of  the 
PMA  battery.  It  was  determined  that  the  PMA  battery  should  be  safe,  rechargeable,  small,  and 
lightweight.  The  PMA  battery  should  also  have  extremely  high  energy  and  power  capacities  and 
should  operate  well  over  a  wide  temperature  range.  The  study  concluded  that  high  capacity 
requires  greater  size  and  weight,  and  that  the  temperature  range  required  for  the  PMA  is  greater 
than  can  be  supported  by  currently  available  technology.  The  Nickel-Cadmium  (NiCad)  battery 
provided  many  desirable  characteristics  and  was  selected  for  the  IMIS  PMA. 

PMA  Mass  Storage  Study.  The  PMA  mass  storage  study  identified  available  and 
developmental  mass  data  memory  technologies  and  assessed  their  respective  characteristics  in 
terms  of  applicability  to  an  IMIS  PMA.  Mass  memory  approaches  and  device  types  examined 


12 


include  magnetic  media,  optical  media,  and  semiconductor  types.  The  requirements  for  the  PMA 
mass  storage  device  include:  large  storage  capacity,  high  speed,  high  reliability,  small  physical 
size,  low  weight,  low  power  dissipation,  and  removable  hard  drive.  Miniature  hard  disk  drives 
provide  most  of  these  characteristics,  but  the  mechanical  moving  parts  design  introduced 
reliability  concerns.  This  information  was  used  in  selecting  a  removable  memory  module  for  the 
PMA. 


PMA  Display  Study.  The  PMA  display  study  identified  and  investigated  available  and 
developmental  display  technologies  and  assessed  their  respective  characteristics  in  terms  of 
satisfying  IMIS  display  requirements.  Major  technology  types  evaluated  include:  cathode  ray 
tubes  (CRTs),  vacuum  fluorescent  displays,  liquid  crystal  displays  (LCDs),  light-emitting  diodes 
(LEDs),  electroluminescent  (EL)  displays,  and  plasma  displays.  None  of  the  available 
technologies  completely  satisfy  all  the  desired  characteristics  of  the  PMA  display.  LCDs  are 
nearly  satisfactory  but  have  limited  ranges  of  both  operating  and  storage  temperatures.  This 
information  was  used  in  selecting  a  display  for  the  PMA. 

PMA  Processor  Study.  The  PMA  processor  study  specified  and  identified  the  most 
suitable  processor  unit  for  the  IMIS  PMA.  Size,  power  consumption,  system  compatibility, 
performance,  and  technology  maturity  were  used  as  discriminators  in  evaluating  the  available 
microprocessors.  This  information  was  used  in  selecting  a  processor  for  the  PMA. 

Aircraft  Interface  Panel  (AIP)  Study.  This  study  was  conducted  by  General  Dynamics 
Fort  Worth  Division,  now  LFWC,  to  define  the  requirements  for  an  on-board  AIP.  This  study 
identified  the  optimal  mix  of  IMIS  functions  to  be  performed  on  the  A/C  and  on  the  ground,  with 
little  or  no  impact  to  A/C  performance  (including  weight,  power,  and  space  requirements).  The 
study  further  defined  functional  and  physical  requirements  for  a  generic  AIP  in  the  form  of  a 
requirements  specification. 

Electromagnetic  Compatibility /Electromagnetic  Interface  Study 

A  preliminary  analysis  of  the  Electromagnetic  Compatibility  (EMC)  requirements  of 
IMIS  was  performed,  using  Military  Standard  461  (MIL-STD-461)  as  a  guideline.  IMIS  can  be 
designated  as  Class  Al,  equipment  and  subsystems  installed  aboard  an  A/C,  including  associated 
ground  support  equipment.  Each  hardware  segment  was  further  identified  as  a  subclass  within 
Class  Al,  according  to  application  environment.  The  AIP  is  intended  to  be  installed  on  the  A/C 
and  was  therefore  designated  as  Class  Alb.  The  PMA  is  considered  aerospace  ground  equipment 
required  for  the  checkout  and  launch  of  the  A/C,  including  electronic  test  and  support  equipment, 
and  was  designated  as  Class  Ale.  The  MIW  is  installed  in  ground  facilities  and  was  designated 
as  Class  Alh. 

Security  Requirements  Study 

The  security  requirements  study  addressed  the  IMIS  security  requirements  for  the  Trusted 
Computer  System,  the  Network  Trusted  Computing  System,  and  the  Trusted  Data  Base 
Management  System  partitions  of  IMIS  in  accordance  with  AFR  205-16.  Fundamental  computer 
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security  requirements,  including  policies  regarding  the  access  to  classified  information,  access 
control  labels,  identification  of  authorized  users,  and  the  recording  of  audit  information,  were 
defined.  This  study  also  provided  a  risk  analysis  to  identify  threats  and  vulnerabilities,  existing 
protective  measures,  and  gaps  or  weaknesses  requiring  additional  or  alternative  protection. 

Mission  and  Support  System  Definition  Study 

The  Mission  and  Support  System  Definition  study  was  conducted  by  performing  three 
Logistic  Support  Analysis  (LSA)  tasks,  in  accordance  with  M1L-STD-1388-1A:  Task  201,  Use 
Study;  Task  202,  Mission  Hardware,  Software,  and  Support  System  Standardization;  and  Task 
203,  Comparative  Analysis. 

The  LSA  Task  201  provided  the  basis  for  all  logistics  planning  and  readiness  analysis  of 
IMIS,  identifying  how,  when,  and  where  IMIS  will  be  used.  The  study  considered  various 
mobility  requirements,  deployment  scenarios,  and  operating  environments  which  influence  the 
design  process,  describing  the  worst-case  scenarios  for  its  intended  use  and  focusing  on  tradeoffs 
between  operational  performance  and  supportability-related  design  features.  Identifying 
operational  characteristics  relevant  to  the  design  for  supportability  allows  shortfalls  to  be 
addressed  early  in  the  design  process. 

LSA  Task  202  resulted  in  the  development  of  system  design  criteria  that  maximize  the 
use  of  existing  and  planned  logistics  support.  It  also  provided  support-related  input  to  mission 
hardware  and  software  standardization  efforts,  including  a  preliminary  software  life-cycle 
support  analysis. 

The  purpose  of  LSA  Task  203  was  to  capitalize  on  information  and  experience  gained 
from  previously  developed  systems  in  identifying  supportability,  cost,  and  readiness  issues  that 
need  to  be  addressed  by  IMIS.  The  current  method  for  performing  maintenance  was  used  as  the 
Baseline  Comparison  System  (BCS)  in  analyzing  the  maintenance  downtime,  active  maintenance 
time,  logistics  delay  time,  and  administrative  delay  time.  This  information  illustrated  the  impact 
of  IMIS  on  the  maintenance  operation. 

IMIS  Simulation 

A  simulation  of  the  entire  operational  maintenance  environment  at  the  O-Level  was 
developed  using  the  IDEF  TO-BE  CA  as  the  initial,  high-level  model  of  IMIS.  This  included  the 
pre-flight  inspections,  A/C  flying  times,  A/C  shutdown  and  pilot  debrief,  thru-flight  and  post¬ 
flight  inspections,  scheduled  maintenance,  and  opening/closing  work  orders.  This  simulation 
tool  can  support  the  following  systems  engineering  studies:  workload  studies,  in  which  the 
queues  and  waiting  times  are  examined  to  identify  any  overused  system  components;  resource 
studies,  in  which  the  quantities  of  maintenance  personnel  and  equipment  are  varied  to  determine 
the  optimal  levels  needed  to  support  a  given  deployment  scenario;  and  sensitivity  studies,  in 
which  probabilities  and  task  times  are  varied  to  evaluate  the  robustness  of  the  system  design. 
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Identification  of  Demonstration  Requirements 


The  SSS  forms  the  basis  for  the  requirements  for  a  full  implementation  of  IMIS. 
Developing  a  demonstration  system  which  meets  all  these  requirements  would  exceed  the 
schedule  and  financial  constraints  for  the  program.  Consequently,  an  approach  for  identifying 
specific  functions  and  requirements  to  be  implemented  and  demonstrated  was  developed. 

The  total  set  of  requirements  identified  in  the  SSS  provided  the  foundation  for  selecting 
the  demonstration  requirements.  During  a  series  of  reviews  between  May  1990  and  March  1991, 
these  requirements  were  prioritized  and  categorized  for  consideration  during  the  demonstrations. 
An  initial  prioritization  of  the  capabilities  categorized  the  requirements  as  mandatory,  desirable, 
or  not  required  for  demonstration.  Detailed  descriptions  of  each  mandatory  and  desirable 
capability  were  then  generated  and  used  for  further  assessment. 

As  a  parallel  effort,  this  set  of  requirements  was  reviewed  by  the  Maintenance  Review 
Panel  (MRP).  The  MRP  was  composed  of  base-level  aircraft  maintenance  personnel  and  several 
members  of  the  IMIS  team,  both  government  and  contractor  personnel,  who  have  Air  Force 
maintenance  experience.  The  charter  of  the  MRP  was  to  serve  as  an  additional  independent 
check  to  ensure  that  the  focus  of  the  IMIS  program  remains  on  its  ultimate  end  users,  the 
maintenance  personnel.  Subsequent  to  these  reviews,  a  preliminary  set  of  demonstration 
requirements  was  approved  and  documented  in  the  first  draft  of  the  Field  Test  and  Demonstration 
Plan,  CDRL  18. 

The  final  step  in  identifying  demonstration  requirements  occurred  between  February  and 
April  1994,  when  the  End-to-End  Demonstration  was  defined.  Capabilities  required  to 
demonstrate  the  end-to-end  flow  of  a  task  within  the  maintenance  environment  were  documented 
in  a  detailed  scenario.  Following  MRP  review  and  approval  of  this  end-to-end  scenario,  the 
preliminary  set  of  demonstration  requirements  was  then  updated  to  reflect  the  deletion  of 
requirements  not  needed  for  any  of  the  field  tests  (Debrief  Test,  End-to-End  Demonstration,  and 
Fault  Isolation  Test). 

The  demonstration  requirements  identified  through  this  process  are  shown  in  Table  1. 
This  table  lists  each  requirement  number,  the  applicable  SSS  paragraph,  and  the  requirement  text. 
Additional  information  regarding  the  interpretation  of,  implementation  of,  and  assumptions 
relating  to  each  requirement  can  be  found  in  Appendix  B  of  the  IMIS  Field  Test  and 
Demonstration  Plan,  CDRL  18. 
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Table  1 .  Demonstration  Requirements 


Rqmt.  Nc 

SSS  Paragraph  No. 

Requirement  Text 

8 

3.2.1. 1.1.1.1- b 

3.2.1. 1.1.1.2- a 

Open  Work  Orders 

9 

3.2.1. 1.1.1.2-a.l 

Assign  Job  Control  Number  (JCN) 

10 

3.2.1. 1.1.1.2-a.2 

Get  work  order  information  from  databases 

11 

3.2.1. 1.1.1.2-a.3 

Enter  work  order  entries  from  Menu  Choiees 

12 

3.2.1.1.I.1.2-b.l 

Access  CAMS  (or  use  technical  data  to  determine  resource  requirements) 

16 

3.2.1. 1.1.1.2-c.l 

Establish  Work  Center  Event  (WCE) 

18 

3.2.1.1.1.1.2-c.2.b 

Notify  roving  truck  of  new  WCE 

19 

3.2.1. 1.1.1.2-C.3 

Identify  and  correlate  PMA  with  specific  individual  or  function 

22 

3.2.1. 1.1.1.2-e.l.a 

Establish  Initial  A/C  Condition  code 

23 

3.2.1. 1.1.1.2-e.l.b 

Establish  Initial  A/C  Status  using  Minimum  Essential  Subsystem  List  fMESLJ 

25 

3.2.1. 1.1.1.2-f.l 

Maintain  mission  status  of  work  orders 

27 

3.2.1. 1.1.1.2-g.l.a 

Notify  maintenance  managers  of  status  changes 

29 

3.2.1. 1.1.1.2-g.2 

Indicate  the  change  in  status  through  audio  or  visual  alerts 

30 

3.2.1. 1.1.1.2-g.3 

Require  operator  response  to  the  alert  (prompt  for  recognition  of  status  change) 

31 

3.2.1. 1.1.1.2-g.4 

Notify  appropriate  Crew  Chief  and  Specialist  Dispatch  of  status  change 

32 

3.2.1. 1.1.1.3-a 

Display  A/C  history  data 

33 

3.2.1. 1.1.1.3-b 

Display  data  regarding  systems  reported  as  deficient  (discrepant) 

34 

3.2.1. 1.1.1.3-d 

Identify  if  the  reported  discrepancies  are  repeat  or  recurring 

35 

3.2.1. 1.1.1.3-e 

Assist  in  determining  required  maintenance  by  comparison  of  similar  histories 

37 

3.2.1. 1.1.1.4-a.3 

Accept  A/C  system  data  manually  to  augment  automatic  process 

40 

3.2.1. 1.1.1.4-b 

Interrogate  systems  for  specific  conditions  or  additional  diagnostic  information 

41 

3.2.1. 1.1.1.4-c 

Accumulate  and  store  all  reported  data  with  the  repair  work  order 

42.A 

3.2.1. 1.1.1.4-d.3 

Analyze  discrepancies,  sortie/flight  data,  and  A/C  and  system  conditions 

43 

3.2.1. 1.1.1.4-d.4 

Access  A/C  history  to  compare  8l  present  information  from  previous  flights 

46 

3.2.1.1.1.1.4-d.7 

Present  debrief  questions  and  query  for  responses 

47 

3.2.1. 1.1.1.4-d.8 

Accept  responses  from  debrief  questions 

48 

3.2.1. 1.1.1.4-d.9 

If  additional  info  is  needed,  modify  debrief  questions  based  on  responses 

59 

3.2.1. 1.1.2.3-a 

Present  TO  inspection  procedures 

64 

3.2.1. 1.1.2.3-e 

Verify  sign  off  authority  of  inspector 

65 

3.2.1.1.1.2.3-f 

Deny  unauthorized  sign  off  of  inspection 
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Table  1.  Continued 


SSS  Paragraph  No. 

Requirement  Text 

3.2.1. 1. 1.3.1 

Provide  access  to  scheduled  flying  and  maintenance  information  for  an  A/C 

69 

3.2.1. 1.1.4.1-a.l 

Set  initial  A/C  status  from  pilot  call-in,  using  the  MESL 

3.2.1. 1.1.4.1-a.2 

Auto  update  initial  A/C  status  based  on  debrief  and  initial  inspect 

71 

3.2.1. 1.1.4.1-b 

Present  updated  status  to  maintenance  managers  for  approval/modification 

72 

3.2.1. 1. 1.4.2 

Control  A/C  status  revisions 

76 

3.2.1. 1. 1.4.3 

Update  estimated  time  in  commission  (ETIC)  based  on  new  information 

93 

3.2.1. 1.1.7.1-a 

Interactively  and  automatically  record  data  from  maintenance  actions 

94 

3.2.1. 1.1.7.1-b 

Automatically  attach  standard  narratives 

95 

3.2.1. 1.1.7.1-c 

Allow  manual  entry  of  narrative  data 

96 

3.2.1. 1.1.7.1-d 

Obtain  information  such  as  name,  AFSC,  etc. ,  from  login  &  personnel  fdes 

97 

3.2.1. 1.1.7.1-e 

Prompt  technician  for  additional  information  needed 

99 

3.2.1. 1.1.7.2-a 

Check  validity  of  data  entered  by  technician 

101 

3.2.1. 1.1.7.2-c 

Reject  and  display  incorrect  data  entries 

102 

3.2.1. 1.1.7.3-a 

Compile  maintenance  data 

103 

3.2.1. 1.1.7.3-b 

Transmit  maintenance  data  to  work  centers  and  external  MDBs 

104 

3.2.1. 1.2.1. 1-a 

Accept  input  of  information  on  assigned  A/C 

108 

3.2.1. 1.2.1. 1-d 

Collect  A/C  status  for  each  A/C 

3.2.1. 1.2.1. 1-e 

Collect  A/C  ETIC  for  each  A/C 

110 

3.2.1. 1.2.1. 1-f 

Review  A/C  status  when  work  order  status  changes 

122 

3.2.1. 1.2.2.3-a 

Monitor  availability  of  specialists  by  AFSC 

123 

3.2.1. 1.2.2.3-b 

Monitor  location  of  specialists 

124 

3.2.1. 1.2.2.3-c 

Monitor  task  qualification  of  specialists 

162 

3.2.1. 1.2.3 .3.b 

Disseminate  A/C  priority  &  configuration  changes  to  maintenance  personnel 

3.2.1.1.2.3.4-a 

Update  flying  and  maintenance  schedule 

3.2.1. 1.2.3.4-c 

Obtain  approval  of  flying  schedule  changes 

— 

3.2.1.1.2.3.4-d 

Distribute  approved  flying  schedules 

3.2.1. 1.2.4.1-c.l.a) 

Provide  status  of  in-progress  maintenance  to  production  managers 

3.2.1. 1.2.4.1-c.l.b) 

Provide  status  of  personnel  assigned  to  A/C  to  production  managers 

182 

3.2.1. 1.2.4.1-C.3 

Allow  data  search  for  more  details  of  current  status 

199 

3.2.1.1.2.4.3-a 

Track  maintenance  personnel  assigned  to  weapon  systems 

201 

3.2.1.1.2.4.3-c 

Coordinate  with  Maintenance  Operations  Center  (MOC)  to  update  work  status 
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Table  1.  Continued 


Rqmt.  Nc 

SSS  Paragraph  No. 

Requirement  Text 

208 

3.2.1. 1.2.5.1-b 

Obtain  qualifications  of  specialists 

209 

3.2.1. 1.2.5. 1-c 

Allow  approval  of  recommended  specialist  assignment 

210 

3.2.1. 1.2.5.1-d 

Allow  alternative  specialist  assignment 

230 

3.2.1. 1.2.5.5-a 

Convey  work  order  to  technician 

232 

3.2.1. 1.3. 1.1 

Provide  maintenance  personnel  access  to  discrepancy  history 

235 

3.2.1. 1.3. 1.3 

Provide  interactive  troubleshooting  guidance 

236 

3.2.1. 1.3. 1.3 

Provide  maintenance  action  recommendations 

237 

3.2.1. 1.3. 1.3-a.l 

Analyze  information  for  fault  isolation 

238 

3.2.1. 1.3. 1.3-a.2 

Provide  maintenance  action  recommendation  based  on  fault  isolation 

246 

3.2.1. 1.3. 1.3-a.7.a) 

Evaluate  time  to  perform  fault  isolation 

247 

3.2.1. 1.3. 1.3-a.7.c) 

Evaluate  parts  availability 

248 

3.2.1. 1.3. 1.3-a.7.d) 

Evaluate  Mean  Time  Between  Failures  (MTBF) 

249 

3.2.1. 1.3. 1.3-a.7.e) 

Evaluate  probable  cause  of  failure 

250 

3.2.1. 1.3. 1.3-a.7 

Recommend  test  sequence  based  on  evaluation 

251 

3.2.1. 1.3. 1.3-a.8 

Provide  reasoning  for  recommending  test  sequence 

253 

3.2.1. 1.3. 1.3-b.l 

Present  theory  of  operations  data  upon  request 

255 

3.2.1. 1.3. 1.3-c.l 

Display  graphics  of  A/C  system  exonerated  w/respect  to  discrepancy 

256 

3.2.1. 1.3. 1.3-C.2 

Present  components  and  test  points  involved  in  troubleshooting 

257 

3.2.1. 1.3. 1.3-C.3 

Present  weapon  system/asset  subsystems  or  components 

258 

3.2.1. 1.3. 1.3-d 

Interpret  module  Built-In-Test  (BIT)  results  without  removing  module 

299 

3.2.1. 1.3. 1.5-a 

Record  troubleshooting  data 

301 

3.2.1. 1.3. 1.5-b.2 

Transmit  troubleshooting  data  to  MDBs 

302 

3.2.1. 1.3. 1.5-c 

Store  troubleshooting  data 

306 

3.2.1. 1.3 .2.2-a.l 

Provide  access  to  supply  information 

309 

3.2.1. 1.3.2.2-a.3 

Process  inventory  requests  for  parts  availability 

311 

3.2.1. 1.3.2.2-b.l.a) 

Identify  the  required  part  by  number 

312 

3.2.1. 1.3.2.2-b.l.c) 

Identify  the  required  part  by  nomenclature 

313 

3.2.1. 1.3 .2.2-b.l.b) 

Identify  the  required  part  by  Work  Unit  Code  (WUC) 

314 

3.2.1. 1.3.2.2-d 

Identify  the  part  in  an  electronic  Illustrated  Parts  Breakdown  (IPB) 

315 

3.2.1. 1.3.2.2-e 

Identify  the  part  using  results  of  fault  isolation 

316 

3.2.1. 1.3.2.2-b.2 

Verify  part  by  displaying  illustration 
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Table  1.  Continued 


Rqmt.  No 

SSS  Paragraph  No. 

Requirement  Text 

318 

3.2.1. 1.3.2.2-b.4 

Identify  necessary  bench  stock/hardware 

319 

3.2.1. 1.3.2.2-b.6 

Verify  correct  part  with  technician 

320 

3.2.1. 1.3.2.2-b.6 

Forward  parts  request  to  SBSS 

321 

3.2.1. 1.3.2.2-b.7 

Accept/Present  SBSS  acknowledgment  of  ordered  part 

324 

3.2.1. 1.3.2.2-c.l 

Verify  technicians  authorization  to  order  parts 

325 

3.2.1. 1.3.2.2-C.2 

Prompt  technician  for  information  required  for  authorization  approval 

326 

3.2.1. 1.3.2.2-C.3 

Route  ordering  information  to  verifier 

327 

3.2.1. 1.3.2.2-C.4 

Notify  parts  orderer  of  unvalidated  order 

328 

3.2.1. 1.3.2.2-C.5 

Notify  orderer  of  SBSS  rejection 

330 

3.2.1. 1.3.2.2-C.8 

Assist  in  correcting  rejected  part  orders 

331 

3.2.1. 1.3.2.2-d.l 

Display  due-out  release  messages  from  SBSS 

337 

3.2.1. 1.3.3. 1-a.l 

Select  and  display  technical  data 

338 

3.2.1. 1.3.3. 1-a.l 

Adjust  TO  data  for  skill  level 

340 

3.2.1.1.3.3.1-a.2 

Provide  status  updates  and  maintenance  discrepancies 

356 

3.2.1. 1.3.3 .3 

Record  data  accumulated  as  result  of  repair/maintenance  action 

366 

3.2.1. 1.3.5. 1-a 

Present  and  sequence  applicable  TO  data 

367 

3.2.1. 1.3.5. 1-b 

Accept  CALS  Type  B  or  Type  C  compatible  data 

368 

3.2.1. 1.3.5. 1-d 

Provide  TO  data  for  PMA  use 

369 

3.2.1. 1.3.5. 1-e 

Query  tech  in  case  of  insufficient  TO  data  in  IMIS 

370 

3.2.1. 1.3.5. 1-c 

Reformat  Type  C  TO  data 

371 

3.2.1. 1.3.5. 1-f 

Provide  supplemental  TO  data 

372 

3.2.1. 1.3.5. 1-g 

Accept  TO  updates 

373 

3.2.1. 1.3.5. l.b 

Manage  currency  of  data  in  PMA 

375 

3.2.1. 1.3.5.2-a.l 

Adapt  technical  data  to  skill  level 

376 

3.2.1.1.3.5.2-a.2 

Adapt  TOs  to  A/C  configuration 

377 

3.2.1.1.3.5.2-a.3 

Adapt  TOs  to  A/C  discrepancy  situation 

378 

3.2.1.1.3.5.2-b 

Provide  increased  detail  upon  request 

379 

3.2.1. 1.3.5.2-c 

Prevent  inexperienced  technicians  from  choosing  displays  with  little  detail 

380 

3.2.1. 1.3.5.3-a 

Present  job-related  information  according  to  technicians  selection 

381 

3.2.1. 1.3.5.3-b 

Displav  related  data  from  other  sources  within  same  TO 

385 

3.2.1. 1.3.5.3-f 

Present  TO  warnings  and  alerts 
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Rqmt.  Nc 

)  SSS  Paragraph  No. 

Requirement  Text 

387 

3.2.1. 1.3.5.3-h 

Adapt  format  to  the  display  device 

388 

3.2.1. 1.3.5.3-i 

Track  and  record  all  TO  steps  taken  during  a  job 

518 

3.2.1. 1.5.1. 1-a 

Provide  familiarization  training  in  the  use  of  IMIS 

521 

3.2.1. 1.5.1. 1-d.l 

Provide  overview  information  of  IMIS 

522 

3.2.1. 1.5.1. l-d.2 

Provide  hardware  and  software  information 

523 

3.2.1. 1.5.1. l-d.3 

Provide  training  tutorials  on  how  to  operate  IMIS 

524 

3.2.1. 1.5. 1.1-e 

Provide  context-sensitive  on-line  help  instructions  in  the  use  of  IMIS 

583 

3.2.1. 1.6.1. 1-a.l 

Initiate  system  coldstart 

584 

3.2.1. 1.6.1. l-a.2 

Load  system  files 

585 

3.2.1.1.6.1.1-a.3 

Configure  system  components 

586 

3.2.1. 1.6.1. 1-b.l 

Initiate  Maintenance  Information  Workstation  (MIW)  coldstart 

587 

3.2.1. 1.6.1. l-b.2 

Load  MIW  system  files 

588 

3.2.1. 1.6.1. l-b.3 

Prompt  operator  for  PMA  information 

589 

3.2.1. 1.6.1. l-b.4 

Provide  listing  of  associated  PMAs 

590 

3.2.1. 1.6.1. 1-c.l 

Provide  PMA  system  files  in  PMAs 

591 

3.2.1. 1.6.1. 1-C.2 

Load  installation  data  in  PMA 

592 

3.2.1. 1.6.1. 1-C.2 

Load  configuration  data  in  PMA 

593 

3.2.1. 1.6.1. 1-C.3 

PMA  establish  communication  with  MIW 

596 

3.2.1.1.6.1.2-a.l 

Initiate  MIW  warm  start 

597 

3.2.1.1.6.1.2-a.2 

Reload  MIW  system  files 

598 

3.2.1.1.6.1.2-a.3 

Reconfigure  MIW  with  PMA  Identifications  (IDs) 

599 

3.2.1.1.6.1.2-b.l.a) 

Reload  PMA  system  files 

600 

3.2.1. 1.6.1.2-b.l.b) 

Reload  PMA-specific  files 

601 

3.2.1.1.6.1.2-b.l.c) 

Reload  system  configuration  data 

602 

3.2.1.1.6.1.2-b.l.d) 

Reload  TO  and  applications  data 

603 

3.2.1.1.6.1.2-b.2 

Reestablish  communications  with  MIW 

605 

3.2.1. 1.6.2.2-a 

Automatically  obtain  data  from  best  source 

606 

3.2.1. 1.6.2.2-b 

Reformat  accessed  data  as  necessary 

607 

3.2.1.1.6.2.3-a 

Automatically  extract  data  to  send  to  MDBs 

608 

3.2.1. 1.6.2.3-b 

Automatically  compile  and  reformat  data  to  send  to  MDBs 

609 

3.2.1. 1.6.2.3-c 

Send  data  to  appropriate  MDBs 

20 
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Rqmt.  No 

SSS  Paragraph  No. 

Requirement  Text 

610 

3.2.1.1.6.2.4-a 

Detect  if  MDBS  are  offline 

611 

3.2.1. 1.6.2.4-b 

Retain  collected  data  if  MDB  is  off  line 

612 

3.2.1.1.6.2.4-c 

Inform  operator  of  off-line  MDB 

619 

3.2.1. 1.6.3. 1-b.l 

Self-test  of  PMA  functional  sections 

621 

3.2.1. 1.6.3. l-b.3 

Test  PMA  interfaces 

625 

3.2.1. 1.6.3. 1-C.4 

Initiate  self-test  of  MI  W 

626 

3.2.1. 1.6.3. 1-C.6 

Interpret  MIW  self-test  results 

3.2.1. 1.6.3. 1-C.5 

Display  MIW  self-test  results 

630 

3.2.1. 1.6.3. 1-C.4.C) 

MIW  self-test  to  include  test  of  all  interfaces 

631 

3.2.1. 1.6.3. 1-C.7 

Save  MIW  self-test  discrepancies  for  which  maintenance  can  be  deferred 

647 

3.2.1. 1.6.4.1-a 

Configure  IMIS  to  work  within  the  specific  base  maintenance  environment 

648 

3.2.1. 1.6.4.1-b 

Load  base-dependent  data  in  IMIS 

649 

3.2. 1.1. 6.4. 1-c 

Establish  communication  interfaces 

651 

3.2.1. 1.6.5. 1-a 

Control  access  to  IMIS  resources 

652 

3.2.1. 1.6.5. 1-b 

Limit  number  of  unsuccessful  attempts  to  access  IMIS 

654 

3.2.1.1.6.5.2-a 

Collect  personal  user  data  at  user  log-in 

655 

3.2.1. 1.6.5.2-b 

Maintain  user  data  for  use  by  all  subroutines 

656 

3.2.1. 1.6.6.1-a 

Convert  TO  data  from  Content  Data  Model  (CDM)  to  run-time  format 

657 

3.2.1. 1.6.6.1-b 

Store  and  manage  converted  TO  data 

658 

3.2.1.1.6.6.2-a 

Provide  English  type  query  language 

660 

3.2. 1.1. 6.6.3 

IMIS  to  have  database  of  user  profiles 

661 

3.2.1. 1.6.6.3-a 

Each  IMIS  user  to  have  one  modifiable  record  in  personnel  database 

662 

3.2.1. 1.6.6.3-c 

Personnel  database  to  include  password 

667 

3.2. 1.1. 6.7 

Include  a  generic  text  editor  for  user  note  generation 

670 

3.2.1. 1.6.8 

Allow  user  to  retrieve  maintenance  instructions  faster  than  paper  medium 

671 

3.2.1. 1.6.8.1-b 

Allow  user  to  move  forward  thru  data,  in  sequence 

— 

Allow  user  to  move  backward  thru  previous  screens 

mm 

Allow  user  to  view  previous  screen 

Allow  user  to  return  to  original  screen  in  sequence 

675 

3.2.1. 1.6.8.2-a 

Select  data  related  to  information  viewed 

n 

3.2.1.1.6.8.2-b 

Allow  multiple  methods  of  data  access 
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Requirement  Text 

677 

3.2.1. 1.6.8.2-c 

Present  options  for  data  display  via  hierarchical  menus 

678 

3.2.1. 1.6.8.2-d 

Display  cross-referenced  information 

679 

3.2.1.1.6.8.2-e 

Return  to  screen  prior  to  requesting  cross-referenced  information 

681 

3.2.1. 1.6.8.2-g 

Display  list  of  available  information 

684 

3.2.1.1.6.8.3-b 

Allow  user  to  quit  or  exit  the  system  or  data  presentation 

685 

3.2.1.1.6.9-a 

Require  minimum  inputs 

686 

3.2.1. 1.6.9-b 

Data  input  via  function  keys 

687 

3.2.1. 1.6.9-c 

Display  function  key  options 

688 

3.2.1. 1.6.9-d 

Support  and  display  user-controlled  cursor  movement 

689 

3.2.1. 1.6.9-f 

Provide  a  Select  capability  for  user  selection  of  functions 

690 

3.2.1. 1.6.9-g 

Echo  user  alphanumeric  input 

692 

3.2.1. 1.6.10-a 

Display  initiation  of  process 

693 

3.2.1. 1.6.10-a 

Display  termination  of  process 

694 

3.2.1. 1.6.10-b 

Display  process  and  expected  duration 

695 

3.2.1. 1.6.10-c 

Display  success  of  the  process 

696 

3.2.1.1.6.10-c 

Display  success  of  the  transaction 

697 

3.2.1. 1.6.11-a 

Support  a  display  function 

698 

3.2.1. 1.6.11-b 

Support,  different  user  groups 

699 

3.2.1. 1.6.11-c 

Present  consistent  data  format  within  and  across  IMIS  segments 

700 

3.2.1. 1.6.11-e 

Present  TO  data  by  expertise  levels 

701 

3.2.1. 1.6.11-g 

Support  zoom  and/or  scroll  functions 

702 

3.2.1. 1.6.12-a 

User  cancellation  or  modification  of  process 

703 

3.2.1. 1.6.12-b.l 

Delete  function  for  correction  of  errors 

704 

3.2.1.1.6.12-b.2 

Undo  function  for  correction  of  errors 

706 

3.2.1. 1.6.12-b.4 

Overwrite  function  for  correction  of  entered  data 

707 

3.2.1. 1.6.13-a 

Provide  context-sensitive  help  on  the  use  of  IMIS 

708 

3.2.1. 1.6.14.1-a 

Notify  MIWs  of  system  termination 

710 

3.2.1. 1.6.14.1-b 

Support  saving  of  all  working  files 

711 

3.2.1.1.6.14.1-c 

Terminate  all  internal  processes 

712 

3.2.1. 1.6.14.1-d 

Terminate  IMIS 

713 

3.2.1. 1.6.14.1-d 

Restart  required  to  resume  operation 
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714 

3.2.1.1.6.14.2 

Initiate  termination  of  MIW 

715 

3.2.1.1.6.14.2-a 

Notify  all  operators  in  communication  with  MIW  of  termination 

716 

3.2.1. 1.6.14.2-b 

Close  and  save  all  MIW  work  files 

718 

3.2.1. 1.6.14.2-e 

Shut  down  the  MIW 

719 

3.2.1. 1.6.14.3-a 

Close  and  save  all  working  files  for  the  PMA 

720 

3.2.1. 1.6.14.3-b 

Terminate  active  internal  PMA  processes 

721 

3.2.1. 1.6.14.3-c 

Notify  MIW  operators  of  shutdown 

722 

3.2.1. 1.6.14.3-d 

Shut  down  the  PMA 

Selection  of  Demonstration  Subsystems 

To  demonstrate  the  IMIS  concept  most  effectively,  enough  TO  data  would  need  to  be 
authored  in  an  electronic  format  to  support  a  completely  paperless  demonstration.  This  would 
require  the  authoring  of  the  Fault  Reporting  Manual  (FRM);  Fault  Isolation  (FI)  Manuals;  job 
guides;  general  system  information  (theory  of  operation);  Illustrated  Parts  Breakdowns  (IPBs); 
pre-,  post-,  and  thru-flight  inspection  procedures;  and  any  second-level  references  to  other  TO 
data  found  in  the  FI  manuals  and  job  guides,  to  include  wiring  diagrams  and  schematics. 

To  provide  this  data  for  all  F-16  subsystems  was  clearly  too  large  and  costly  a  task.  The 
Statement  of  Work  initially  limited  the  demonstration  to  five  subsystems:  two  avionics  systems, 
one  hydraulic  system,  one  engine  subsystem,  and  one  environmental  system.  Also,  in  planning 
for  an  unconstrained  demonstration  in  which  IMIS  would  be  used  to  maintain  operational  A/C 
and  correct  real  discrepancies,  it  was  believed  that  selecting  subsystems  with  the  highest  failure 
rates  in  these  categories  would  provide  the  most  opportunities  to  collect  information  for 
subsequent  analysis. 

The  Fire  Control  Radar  (FCR)  and  Head-Up  Display  (HUD)  were  selected  as  the  two 
avionics  systems  because  of  their  high  failure  rates.  Both  of  these  systems,  however,  are  located 
on  the  MIL-STD-1553  D-MUX  bus,  which  is  accessed  through  the  Fire  Control  Computer 
(FCC),  also  called  the  General  Avionics  Computer  (GAC),  behind  a  large  panel.  Accessing  the 
1553  D-MUX  bus  was  not  feasible  for  the  unconstrained  demonstration,  because  of  both  the  time 
required  to  remove  the  panel  and  the  risk  of  damage  in  the  process  of  disconnecting  and 
reconnecting  electrical  connectors.  A  better  solution  for  retrieving  information  directly  from  the 
A/C  via  the  1553  MUX  buses  would  be  to  access  the  A-MUX  and  B-MUX  buses.  Upon  further 
evaluation,  the  Inertial  Navigation  Set  (INS)  subsystem  was  selected  to  replace  the  engine 
subsystem.  As  a  result,  the  following  five  subsystems  were  identified  for  the  demonstrations: 

Fire  Control  Radar  (Work  Unit  Code  (WUC)  74A00) 

Head-Up  Display  (WUC  74B00) 
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Inertial  Navigation  Set  (WUC  74D00) 

Hydraulic  Power  Supply  (WUC  45 AGO) 

Cabin  Pressurization  (WUC  41  BOO) 

The  ease  of  simulating  and  inserting  faults  via  breakout  boxes  was  considered  in  the 
selection  of  subsystems  for  the  Fault  Isolation  Test.  Consequently,  the  FCR,  HUD,  and  INS 
subsystems  were  selected.  A  complete  description  of  the  faults  used  during  the  Fault  Isolation 
Test  can  be  found  in  the  section  of  this  volume  entitled,  “Fault  Isolation  Test.” 


HARDWARE  DESIGN 

The  requirements  analysis  described  in  the  preceding  section  identified  the  key 
requirements  to  be  supported  by  the  IMIS  demonstration  system.  The  IMIS  hardware  needed  to 
provide  access  to  external  databases,  portable  devices  for  use  on  the  flightline,  and  the  capability 
to  communicate  maintenance  data  and  maintenance  decisions  to  all  affected  personnel.  The 
optimal  IMIS  configuration  therefore  consists  of  three  system  segments:  the  Maintenance 
Information  Workstation  (MI^V0,  the  PMA,  and  the  AIP.  Figure  4  depicts  the  configuration  of 
the  IMIS  demonstration  system  as  installed  at  Luke  AFB.  A  third  MIW  was  added  to  the 
network  to  support  integration  and  demonstration  activities. 
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The  MIW  segment  provides  an  interface  to  the  external  data  systems  and  to  the  PMA. 
The  MIW  automatically  retrieves  the  information  needed  to  perform  MIW  functions  from  the 
external  sources  and  provides  the  capability  to  transmit  data  to  these  external  sources.  The  MIW 
provides  data  to  the  PMA  to  support  the  PMA  functional  requirements,  both  at  the  beginning  of  a 
task  (by  preparing  a  cartridge)  and  during  a  task  (by  sending  data  and  messages  over  the  RF 
link).  The  MIW  also  serves  as  a  user  station  for  personnel  who  do  not  perform  their  main  tasks 
on  the  flightline  (e.g.,  maintenance  debriefers  and  Maintenance  Operations  Center  [MOC] 
personnel). 

The  PMA  segment  provides  an  interface  for  all  flightline  personnel,  both  technicians  and 
managers,  to  the  other  IMIS  segments.  The  PMA  is  used  by  managers  to  monitor  A/C  status, 
personnel  assignments,  and  flying  and  maintenance  schedules.  The  PMA  is  used  by  the 
technicians  to  open  and  close  work  orders,  to  perform  diagnostics,  and  to  display  TOs.  The 
PMA  transmits  collected  data  to  the  MIW  for  storage,  dissemination  to  other  personnel,  and/or 
forwarding  to  external  databases,  as  required. 

The  AIP  segment,  in  a  full  IMIS  implementation,  provides  the  interface  between  the 
PMA  and  on-board  diagnostic  computer  system.  For  the  IMIS  demonstration,  the  AIP  was  a 
portable  mockup  used  to  demonstrate  potential  applications  for  the  AIP. 


The  way  in  which  the  IMIS  segments  must  interface  with  one  another  was  also 
considered.  Each  segment  provides  multiple  methods  for  interfacing  with  the  others  to  ensure 
that  critical  data  can  be  distributed  throughout  the  system.  Figure  5  provides  an  overview  of  the 
interfaces  between  the  three  IMIS  hardware  segments,  as  well  as  the  external  interfaces  with  the 
F-16  A/C  (via  the  1553  bus)  and  the  legacy  databases  (via  the  Standard  Base-Level  Computer 
[SBLC]). 


IMIS 

SEGMENTS 


MEMORY  MODULE 


Figure  5.  IMIS  Segment  Interfaces 
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The  following  subsections  document  the  hardware  design  of  the  IMIS  demonstration 
hardware.  Additional  detail  regarding  the  hardware  requirements  and  design  can  be  found  in  the 
Prime  Item  Development  Specifications  (PIDS),  CDRL  22,  and  the  Prime  Item  Product 
Fabrication  Specifications  (PIPFS),  CDRL  23. 

Maintenance  Information  Workstation  (MIW) 

The  MIW  communicates  with  external  information  systems  and  other  IMIS  segments  to 
provide  an  integrated  source  of  information  for  all  maintenance  personnel.  When  selecting  the 
hardware  for  the  demonstration  system,  a  trade  study  was  performed  to  identify  the  commercial 
which  could  support  the  functional  requirements  and  contractual  requirements  within 
the  cost  constraints.  Included  in  the  list  of  functional  requirements  were  performance,  off-the- 
shelf  applicability,  expandability  and  upgrades,  software  availability,  and  programmatics,  such  as 
cost,  schedule,  familiarity,  and  availability.  Figure  6  shows  the  hardware  components  selected 
for  the  MIW  as  a  result  of  this  trade  study,  their  interconnection,  and  the  connection  to  other 
IMIS  segments,  as  well  as  to  systems  outside  IMIS. 


PMA/AIP- 

SBLC 

Interface*" 


RS-232 


RS-232 
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RS*232 
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SPARC  CPU 


KEYBOARD 


207  MB 
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SYSTEM  INTERFACE 
(SCSI) 


1.3  GB 


8  mm 
TAPE 
DRIVE* 


CD  ROM* 


*  SUPPLIED  ON  ONE  OF  TWO  MIWS 
Figure  6.  MIW  Segment  Interfaces 


The  workstation  consists  of  a  Sun  SPARCstation  2  Central  Processing  Unit  (CPU),  a  19- 
inch  (48.3-centimeter)  color  display,  keyboard,  mouse,  an  internal  1.44  megabyte  (MB)  3.5-inch 
(8.9-centimeter)  floppy  disk  drive,  and  a  207-MB  internal  Winchester  disk  drive.  Interfaces 
external  to  the  main  workstation  include  external  disk  storage  systems  which  provide  1.3 
gigabytes  (GB)  of  storage  space,  an  8-mm  tape  drive,  a  laser  printer,  and  a  Compact  Disk  Read- 
Only  Memory  (CD  ROM).  The  network  connection  between  the  MIWs  allows  these  devices  to 
be  accessed  and  controlled  from  any  MIW. 
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Electronic  communications  between  the  MIW  and  the  LAN  are  provided  by  an  Ethernet 
connection.  This  allows  the  MIWs  to  communicate  with  one  another,  to  communicate  with  the 
Memory  Module  Loader  (MML),  and  to  be  connected  to  any  other  computer  system  with  a 
compatible  Ethernet  interface. 

An  RF  link  provides  the  interface  between  the  MIW  and  PMA  segments.  The  MIW 
interface  to  the  RF  module  is  through  the  Radio  Standard  (RS)-232  compatible  serial  ports.  The 
PMA  and  MIW  segments  are  also  able  to  communicate  via  an  RS-232  interface.  The  link  was 
primarily  for  use  during  development  but  is  available  to  serve  as  an  alternate  means  of  MlW-to- 
PMA  communications. 

The  MIW  has  the  capability,  via  the  MML,  to  download  data  to  and  upload  data  from  a 
PMA  memory  module,  which  contains  340  MB  of  non-volatile  storage.  The  486-based  MML  is 
connected  to  the  MIW  network.  The  MML  provides  a  gateway  between  the  central  database, 
which  exists  in  the  SunOS  environment,  and  the  local  subset  of  the  central  database  created  for 
each  PMA  or  AIP,  which  exists  in  the  Santa  Cruz  Operation  (SCO)  UNIX  environment. 

The  MIW  communicates  with  the  SBLC  via  an  RS-232  interface.  This  conneetion  is 
routed  through  the  Computer  Logics  Synchronous  Adaptor  (CLSA)  device  and  a  series  of  9600- 
baud  modems  which  send  data  to  and  receive  data  from  the  Unisys  mainframe  housing  CAMS. 

Portable  Maintenance  Aid  (PMA) 

The  PMA  collects,  processes,  and  integrates  the  data  entered  directly  or  received  through 
interfaces  with  the  MIW  and  the  AIP.  The  PMA  provides  the  maintenance  technician  detailed 
information  regarding  maintenance  tasks  while  on  the  flightline.  The  technician,  through 
keyboard  control  and  displayed  instructions,  uses  the  PMA  to  diagnose  maintenance  faults.  The 
PMA  can  communicate  with  the  MIW  to  order  parts  and  report  status. 

The  original  PMA  was  based  on  a  standard  commercial  laptop  computer  attached  to  an 
external  chassis  which  would  provide  the  RF  and  1553  interfaces.  The  work  performed  in 
Phases  I  and  II  showed  that  this  approach  would  not  result  in  the  best  demonstration  of  the  IMIS 
capabilities.  Therefore,  a  trade  study  was  performed  to  find  the  best  solution.  The  PMA  Trade 
Study  compared  many  alternatives,  some  based  on  commercial  off-the-shelf  (COTS)  equipment 
and  others  representing  new  design  options. 

In  support  of  the  study,  data  was  gathered  regarding  the  human  factors  considerations  of 
the  PMA  device.  Mock-ups  of  proposed  PMA  chassis  designs  were  presented  to  personnel  at 
Edwards  AFB,  and  the  information  collected  was  considered  in  the  trade  study.  The  findings  of 
the  Edwards  AFB  demonstrations  show  that  the  new  PMA  case  design  allows  the  unit  to  be 
lifted,  held,  carried,  and  used  in  a  way  which  works  well  at  and  around  the  flight  line.  The 
resulting  PMA  design,  including  the  visual  displays,  keypads,  and  controls,  uses  the  applicable 
human  engineering  standards  of  MIL-STD-1472  as  guidelines.  The  anthropometric  and  human 
performance  aspects  of  the  PMA  design  were  considered  throughout  the  PMA  development  to 


27 


optimize  man-machine  interface  effectiveness  and  minimize  training  requirements.  The  PMA 
chassis  is  shown  in  Figure  7. 


Figure  7.  PMA  Chassis 


The  PMA’s  internal  and  external  interfaces  are  shown  in  Figure  8  along  with  the  PMA’s 
major  components. 

The  CPU  is  a  33-megahertz  (MHz),  80486DX-based,  single-board  computer.  In  addition 
to  the  basic  computer  capability,  the  single-board  computer  provides  a  Video  Graphics  Array 
(VGA)  video  output,  two  serial  ports,  one  parallel  port,  a  hard  disk  interface,  a  PC-AT  bus 
expansion  interface,  and  a  total  of  32  MB  of  random  access  memory  (RAM).  The  original 
design  called  for  a  20-MHz,  80386SX-based  CPU  with  4  MB  of  RAM.  Early  testing  showed 
that  the  computations  performed  while  executing  the  diagnostics  algorithms  and  other  functions 
required  additional  speed  and  memory.  The  upgraded  CPU  and  memory  provide  significant 
improvements  to  the  PMA’s  performance. 

The  display  is  a  640-X-480  VGA,  transflective  LCD  unit.  The  display  can  be  viewed  in 
direct  sunlight  without  the  use  of  a  backlight  or  in  darkness  with  a  backlight.  The  backlight  is 
integrated  into  the  display  module. 


28 


POWER  (MIW/AIP)  (MIW)  (AIRCRAFT/AIP) 

*  ACRONYMS: 

CCA  =>  CIRCUIT  CARD  ASSEMBLY 

IDE  =>  INTELLIGENT  DRIVE  ELECTRONICS 

CHA  =>  CHANNEL  A 

Figure  8.  PMA  Segment  Interfaces 

The  PMA  uses  a  non-volatile  memory  module,  which  is  programmed  by  a  MML 
connected  to  the  MIW.  This  memory  module’s  contents  include  TO  data,  as  well  as  fault 
isolation  and  diagnostics  data  for  the  selected  subsystem.  The  memory  module  in  the  original 
design  provided  60  MB  of  storage.  As  technology  matured,  the  mass  storage  capacity  grew  to 
the  340  MB  hard  drive  used  in  the  PMA  tested. 

Communication  between  the  PMA  and  MIW  is  accomplished  through  an  RF  link.  The 
RF  module  provides  spread  spectrum  communications  over  the  frequency  range  from  902  MHz 
to  928  MHz.  The  frequency  used  at  Luke  AFB  was  906  MHz.  The  RF  module  provides  four 
independent  channels  and  individual  receiver  addressing.  The  RF  modules  operate  in  a 
packetized  mode  such  that  radio  control,  data,  and  status  messages  are  passed  between  the 
computer  and  RF  module  over  the  same  interface. 

The  keypad  is  a  matrix  of  membrane  switches  which  provide  the  primary  UI  to  the  PMA. 
These  switches  provide  tactile  feedback  and  are  resistant  to  jet  fuel  and  most  other  solvents. 

The  battery  module  is  a  rechargeable  NiCad  battery  pack.  This  unit  provides  a  nominal 
7.2-volt  direct  current  (DC)  output  for  use  by  the  PMA.  In  addition,  the  battery  pack  provides  a 
temperature-sensor  output  for  use  during  quick  charge.  The  PMA  may  also  be  operated  from  an 
external  power  source. 


Aircraft  Interface  Panel  (AIP) 

The  AIP  was  designed  as  a  laboratory  demonstration  imit  which  demonstrated  the 
capability  to  communicate  A/C  information  to  the  PMA.  The  1553  Avionics  Self-Test  Bus  is 
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used  for  this  communication,  and  the  AIP  is  able  to  send  data  to  and  receive  data  from  the  PMA 
via  this  bus.  The  AIP  uses  a  removable  non-volatile  Memory  Module,  identical  to  that  used  on 
the  PMA,  to  hold  its  data  files  and  software.  This  memory  module’s  contents  include  TO  data  as 
well  as  fault  isolation  and  diagnostics  data  for  the  AJC.  The  goal  of  the  demonstration  AIP 
design  was  to  represent,  as  closely  as  possible,  an  actual  AIP  that  would  be  embedded  in  an  A/C. 

When  these  requirements  were  delineated,  it  was  noted  that  the  demonstration  AIP 
required  functionality  which  was  very  similar  to  that  of  the  PMA.  As  a  result,  the  AIP  used  the 
internal  components  of  the  PMA  to  the  extent  possible.  With  the  exception  of  the  RF  modem 
(required  on  the  PMA  but  not  on  the  AIP),  the  internal  electronics  of  the  two  devices  were 
identical,  as  is  shown  in  Figure  9. 


EXTERNAL 

POWER 


MODULE  RS-232  CH  A  CH  B 

(MIW)  (MIW/PMA)  (AIRCRAFT/PMA) 

Figure  9.  AIP  Segment  Interfaces 


Since  the  AIP  was  a  functional  mockup  of  a  device  which  would  eventually  be  installed 
on  an  A/C,  its  chassis  design  was  quite  different  from  that  of  the  PMA.  The  AIP  was  housed  in  a 
metal  chassis  which  gave  the  appearance  of  a  line  replaceable  unit  (LRU).  Handles  were  placed 
on  the  front  to  allow  for  easy  removal  and  replacement.  Figure  10  shows  a  rough  outline  of  the 
front  panel  of  the  AIP. 


SOFTWARE  DESIGN 

The  IMIS  is  an  integrated,  user-oriented  system  that  improves  the  effectiveness  and 
efficiency  of  the  O-Level  maintenance  personnel  who  maintain  and  support  selected  F-16  C/D 
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Block  40/42  A/C  subsystems.  The  IMIS  software  has  been  designed  to  support  the  complex 
maintenance  tasks  that  are  performed  by  these  personnel  by  processing,  integrating,  and 
displaying  information  from  various  sources.  IMIS  interfaces  with  external  systems  and  supports 
their  data  and  operational  requirements,  thereby  providing  a  single  system  with  which 
maintenance  personnel  can  perform  their  day-to-day  maintenance  activities. 


IMIS  allows  the  user  to  extract  many  combinations  of  information  without  requiring 
complicated  command  sequences.  By  providing  simple  access  to  this  information,  IMIS 
facilitates  the  user's  ability  to  perform  troubleshooting  and  decision  support.  IMIS  also  has  the 
ability  to  interface  with  the  F-16  C/D  Block  40/42  on-hoard  diagnostics  and  to  translate 
information  received  during  fault  verification  for  use  in  fault  isolation. 

The  IMIS  system  is  composed  of  an  IMIS  Computer  Software  Configuration  Item 
(CSCI),  an  MIW  component,  a  PMA  component,  and  an  AIP  component.  The  IMIS  CSCI 
encapsulates  all  the  software  functions  associated  with  the  user  interface,  maintenance, 
management,  and  diagnostics  capabilities  as  described  in  the  Software  Requirements 
Specification  (SRS).  The  purpose  of  the  IMIS  CSCI  is  to  specify  a  single  software  design  in 
terms  of  abstractions  (system  classes)  and  generic  services  that  can  be  used  as  the  baseline  for 
modification  to  execute  on  all  the  MIW,  PMA,  and  AIP  components  of  IMIS.  Thus,  the  need  to 
specify  a  unique  software  design  for  each  IMIS  component  is  avoided. 

This  section  documents  the  software  design  for  the  demonstration  IMIS  system.  This 
includes  a  discussion  of  the  object-oriented  methodology  used  and  the  resulting  software 
development  environment  selected,  an  overview  of  the  software  architecture,  and  a  summary  of 
the  requirements  and  design  in  each  of  the  major  functional  areas;  user  interface,  diagnostics, 
TO  presentation,  message  manager,  external  data  management,  and  PMA-unique  software. 
Additional  detail  regarding  the  software  design  can  be  found  in  the  IMIS  Software  Design 
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Document  (SDD),  CDRL  26.  Other  supplemental  information  contained  in  the  SDD  includes 
State/Transition  Diagrams,  presentation  storyboards,  pseudo-code,  class  library  structures,  and 
attribute  definitions. 


Object-Oriented  Design 

The  objected-oriented  design  paradigm  is  really  a  modeling  point  of  view.  The  analysis 
and  design  phases  of  the  traditional  life  cycle,  while  remaining  distinctly  separate  activities  in  the 
object-oriented  life  cycle,  work  together  closely  to  develop  a  model  of  the  problem  domain.  The 
model  IS  constructed  by  viewing  the  domain  as  a  set  of  interacting  entities.  The  software-based 
models  of  entifies  and  the  relationship  between  them  are  assembled  to  form  the  basic  architecture 
of  the  application.  The  information  developed  in  the  analysis  phase  becomes  an  integral  part  of 
the  design  rather  than  simply  providing  input  into  the  phase.  This  smooth  transition  is  facilitated 
by  the  homogeneity  of  the  "pieces"  being  used  by  each  process. 

The  IMIS  software  requirements  are  expressed  in  terms  of  abstractions  (system  classes  in 
the  object-oriented  methodology)  and  generic  services  that  can  be  used  as  the  basis  for  tailoring. 
The  approach  assists  the  software  design  process  by  partitioning  the  software  into  distinct  system 
capabilities.  The  capabilities  of  IMIS  are  expressed  in  terms  of  the  problem  domain  concepts 
These  concepts  correspond  to  software  classes  whose  behaviors  provide  the  required  capability. 
This  approach  to  expressing  the  requirements  is  to  facilitate  an  object-oriented  design  paradigm, 
as  opposed  to  the  traditional  procedural  paradigm. 

Major  benefits  of  an  object-oriented  development  approach  include  reusability  and 
extensibility.  Given  the  nature  of  the  IMIS  program,  it  was  believed  that  the  object-oriented  path 
would  provide  the  greatest  benefit  during  the  development  of  the  demonstration  system  and 
extending  into  full  system  development. 

Software  Development  Environment 

The  IMIS  software  development  environment  was  chosen  to  support  object-oriented 
analysis,  design,  and  programming.  The  essential  requirements  were  based  on  the  need  for  a 
repository  approach  to  software  development,  where  products  of  the  software  development 
process  are  integrated  into  a  single  repository.  This  provides  facilities  for  evolutionary 

development  and  presumes  an  application  architecture  designed  to  facilitate  change,  which  is 
necessary  for  IMIS. 

The  IMIS  software  development  environment  was  chosen  to  support  object-oriented 
analysis,  design,  and  programming.  The  IMIS  software  development  environment  is  an 
integrated  environment  centered  on  the  ONTOS  object-oriented  database  as  the  central 
repository.  Associative  Design  Technology’s  Ptech  was  selected  to  act  as  the  front  end  for  the 
object-oriented  database  repository.  This  provided  a  high  degree  of  integration  for  the  design 
representations,  in  that  the  conceptual  models  go  directly  into  the  ONTOS  database  in  terms  of 
class  libraries  and  process  implementations. 
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The  IMIS  software  development  occurred  before  technology  was  sufficiently  mature  to 
support  object-oriented  analysis,  design,  and  programming.  The  tools  described  in  the  following 
subsections  were  selected  because  of  the  potentially  significant  benefits  which  could  be  realized 
by  using  this  repository  approach. 

Computer-Aided  Software  Engineering  Tools 

The  primary  Computer-Aided  Software  Engineering  (CASE)  tool  used  was  Ptech.  Ptech 
offers  an  integrated  approach  that  describes  processes  and  systems  at  all  levels  of  detail,  from 
requirements  through  design  and  implementation.  It  provides  a  flexible  front-end  method  and 
tool  that  intimately  links  classes  and  processes.  Ptech  provided  a  formal  foundation  to  allow  the 
Air  Force  maintenance  domain  concepts  to  be  mapped  exactly  onto  the  C++  typing  system  and, 
as  a  result,  was  used  to  develop  correct,  consistent,  and  executable  specifications  of  many  of  the 
maintenance  processes.  This  meant  that  the  way  the  maintenance  experts  specified  the  problem 
determined  precisely  how  the  software  engineers  thought  about  the  problem;  concepts  specified 
by  the  maintenance  user  were  automatically  preserved  in  code.  The  C++  code  that  was  generated 
was  ready  for  insertion  into  an  ONTOS  object-oriented  database,  providing  a  direct  bridge 
between  the  concept  in  the  Ptech  knowledge  base  and  classes  (and,  subsequently,  instances  of 
classes)  in  ONTOS. 

Database  Management  Systems 

Due  to  the  object-oriented  nature  of  the  IMIS  software  development,  an  object-oriented 
database  selection  was  necessary.  The  ONTOS  database,  written  entirely  in  C++,  was  the  only 
third-generation  object  database  based  on  an  architecture  of  "objects  throughout"  in  which 
objects  were  implemented  at  every  level  of  the  database  system,  from  the  object  model,  storage 
managers,  and  memory  managers  to  the  data  types  and  access  methods.  This  architecture 
provided  developers  with  an  open  interface  and  flexible  access  to  all  the  capabilities  of  the 
database  through  class  libraries  and  associated  tools.  ONTOS  offered  the  functionality  and  a 
comprehensive  tool  set  needed  to  develop  network-based  distributed  database  applications.  In 
particular,  the  High  Concurrency  Object  (HCO)  technology  allowed  multiple  users  to  access  and 
update  specific  objects  simultaneously.  This  provided  a  significant  increase  in  concurrency  on 
critical  objects  used  in  the  multi-user  application. 

ONTOS  did  not  appear  to  be  suitable,  however,  as  a  vehicle  for  interfacing  with  a  screen- 
oriented  external  system,  such  as  CAMS.  As  a  result,  Sybase,  a  relational  database  management 
system,  was  selected  to  serve  as  an  intermediate  data  repository  between  the  two  dissimilar 
systems.  This  selection  also  would  allow  for  extensions  to  other  external  databases  in  the  future 
with  minimal  impact. 

Programming  Languages 

In  selecting  C++  and  C  as  the  programming  languages  for  the  IMIS  software 
development  environment,  two  constraints  were  considered.  The  first  constraint  was  that  a 
custom  application  communicating  with  ONTOS,  the  IMIS  object-oriented  database,  can  be 
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written  using  C++  but  not  C.  The  second  constraint  is  that  the  Sybase  Application  Programming 
Interface  (API),  used  in  the  External  Data  Management  (EDM)  software,  can  be  invoked  by 
applications  written  in  C  but  was  not  recommended  for  applications  written  in  C++. 
Consequently,  all  IMIS  software  has  been  written  in  C++,  with  the  exception  of  various  EDM 
functions,  written  in  C,  which  invoke  the  Sybase  API. 

User  Interface  Tools 


The  software  tools  used  to  implement  the  UI  software  are  the  ParcPlace  User  Interface 
Builder  (UIB)  and  the  Object  Interface  (01)  Toolkit.  UIB  is  a  graphical  UI  tool  designed  to  work 
with  the  01  Toolkit  to  produce  graphical  presentations  on  underlying  classes,  and  allow 
automatic  update  of  class  attributes  displayed  and  modified  in  the  presentations.  Callback 
routines  are  attached  to  the  component  widgets  used  to  design  and  display  the  class  attributes.  In 
addition,  UIB  allows  the  developer  to  encase  the  presentations  in  X- Window-based  windows, 
which  are  manipulated  like  other  windows  in  an  X-based  system.  These  windows  can  have 
menu  systems  designed  by  the  developer  with  their  associated  callbacks.  The  UI  paradigms 
presentations,  described  further  in  the  subsection  entitled,  “Diagnostics,”  are  implemented 
directly  with  facilities  provided  by  UIB. 

The  01  Toolkit  is  an  object-oriented  toolkit  built  on  the  X-lib  layer  of  the  X- Window 
system.  It  provides  a  rich  set  of  widget  functionality  based  on  a  class  hierarchy  structure.  The 
IMIS  UI  software  utilizes  the  01  Toolkit  to  develop  complex  widgets  which  cannot  be 
implemented  with  UIB. 


Software  Architecture  Overview 

IMIS  is  a  multi-user  application  that  operates  on  the  MIW,  PMA,  and  AIP.  The 
architecture  provides  the  user  with  functionality,  data,  and  a  UI  that  is  consistent  across  these 
different  platforms.  The  architecture  consists  of  transactions  and  services  that  share  a  common 
class  library.  The  services  and  transactions  are  the  processes  which  access  and  manipulate  the 
class  library.  The  class  library  contains  all  reusable  components  of  IMIS  software. 

A  transaction  is  defined  as  an  end-user  task  or  unit  of  work.  Each  transaction  is  an 
interaction  with  the  IMIS  user.  All  transactions  are  implemented  in  a  single  process  called  the 
IMIS  process.  The  IMIS  process  manages  all  user  interaction  and  functional  capability  for  the 
IMIS  user.  These  capabilities  include  the  ability  to  view  and  manipulate  IMIS  data,  including 
user,  personnel,  A/C,  work  order,  schedule,  and  part  data. 

A  service  is  defined  as  providing  a  capability  not  directly  visible  to  the  user.  Services 
typically  involve  an  external  or  operating  system  interface.  The  EDM  and  CAMS  Interface 
services  provide  an  interface  to  external  systems  such  as  SBSS  and  CAMS.  The  Message 
Manager  service  provides  communication  between  the  ONTOS  databases  that  reside  on  the 
PMAs  and  the  ONTOS  database  that  resides  on  the  MIW  network.  The  MML  service  moves 
instance  information  from  the  ONTOS  database  on  the  MIW  network  into  an  ONTOS  database 
on  the  PMA. 
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The  class  library  contains  reusable  software  required  to  implement  the  transactions  and 
services.  The  class  library  is  subdivided  into  IMIS,  EDM,  System,  Content  Data  Model  (CDM), 
and  Diagnostics  class  libraries.  The  IMIS  class  library  provides  the  classes  necessary  to  support 
all  IMIS  processes  except  diagnostics.  The  EDM  class  library  supports  the  transfer  of  data 
between  ONTOS  and  Sybase.  The  System  class  library  is  used  to  manage  the  user's  environment 
and  to  manage  the  movement  of  data  between  the  IMIS  processes  and  within  a  single  IMIS 
process.  The  System  class  library  is  also  used  to  manage  the  transfer  of  data  between  the  IMIS 
processes  and  the  services.  The  CDM  class  library  contains  electronic  TO  data  and  related 
troubleshooting  information  to  support  automated  diagnostics  and  interactive  presentation  of 
maintenance  and  repair  instructions,  illustrations,  and  parts  information.  The  Diagnostics  class 
library  supports  the  diagnostic  process. 

The  system  is  configured  so  that  an  IMIS  process  executes  on  each  platform  in  the 
system.  This  provides  a  consistent  interface  to  the  user.  However,  resources  are  not  allocated 
uniformly  across  all  platforms.  The  method  of  accessing  resources  on  the  system  differs 
depending  on  the  type  of  platform,  resulting  in  different  configurations,  as  described  m  the 

following  paragraphs. 

MIW  Architecture 


The  MIW  Network  architecture  consists  of  IMIS  processes  and  services  sharing  the 
central  database.  The  resources  that  are  unique  to  the  MIW  Network  architecture  are  the  central 
database  and  the  external  interface  to  other  database  systems. 

The  central  database  contains  the  current  information  for  the  IMIS  system.  The  Message 
Manager  service  maintains  consistency  between  peripheral  databases  and  the  central  database. 
The  Message  Manager  also  provides  communication  between  IMIS  processes  located  on  the 
PMAs  and  the  services  located  on  the  MIW  network. 


The  external  interface  to  other  database  systems  consists  of  an  EDM  process,  the  Sybase 
database,  and  a  CAMS  process.  The  EDM  process  converts  objects  in  the  ONTOS  database  into 
their  reliional  equivalents  and  stores  the  data  in  Sybase  when  moving  data  from  IMIS  to  an 
external  system.  When  moving  data  from  an  external  system  to  IMIS,  the  inverse  set  of 
operations  is  performed.  The  EDM  process  is  responsible  for  maintaining  consistency  between 
the  ONTOS  database  and  the  external  databases.  The  CAMS  process  provides  communication 
services  by  moving  data  from  Sybase  to  an  external  database  and  vice  versa. 


PMA  Architecture 

The  PMA  architecture  consists  of  an  IMIS  process  and  a  local  copy  of  the  ONTOS 
database.  The  local  database  acts  as  a  buffer  for  shared  objects  and  messages.  The  shared 
objects  and  messages  are  integrated  into  the  central  database  using  the  Message  Manager.  Static 
data  such  as  the  CDM  are  stored  in  the  local  database  so  that  the  IMIS  process  can  provide 
efficient  transactions  for  the  user.  The  PMA  contains  the  unique  1553  device  driver  software. 
The  process  provides  this  capability  when  in  the  PMA  or  AIP  configurations. 
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AIP  Architecture 


The  AIP  architecture  is  identical  to  that  of  the  PMA  with  one  exception:  the  AIP  is  not 
capable  of  network  communication  over  the  RF  link  using  the  Message  Manager. 
Synchronization  and  consistency  between  the  local  database  and  the  central  database  are 
achieved  by  first  downloading  shared  objects  and  messages  to  a  PMA  via  the  1553  external  bus 
connection  available  on  the  PMA  and  AIP  configurations,  and  then  integrating  the  shared  objects 
and  messages  into  the  central  database  using  the  Message  Manager  via  the  RF  link  available  on 
the  PMA  configuration. 

MML  Architecture 

The  MML  architecture  is  an  extension  of  the  MIW  Network  architecture,  which  provides 
a  gateway  between  the  central  database,  which  exists  in  the  SunOS  environment,  and  the  local 
subset  of  the  central  database  created  for  each  PMA  or  AIP,  which  exists  in  the  SCO  UNIX 
environment.  The  sole  function  of  the  MML  is  to  provide  a  platform  for  loading  PMA/AIP  local 
databases  onto  Memory  Modules  and  to  extract  data  from  the  Memory  Modules  in  order  to  store 
it  into  the  IMIS  or  external  databases.  The  MML  performs  this  service  via  the  MIW  Network 
architecture. 


User  Interface 

The  UI  software  was  designed  to  be  as  reusable  as  possible,  from  both  a  development 
perspective  and  a  user-friendly  perspective.  The  initial  set  of  UI  paradigms  was  identified  based 
on  a  knowledge  of  project  requirements,  high-level  system  design,  and  prototyping  efforts. 
These  paradigms  were  generic  in  nature  and  therefore  reusable  across  a  wide  variety  of 
applications.  Specific  screen  states  and  state  transition  diagrams  were  developed  with  these 
generic  paradigms  in  mind.  This  process  maximized  software  reuse  in  terms  of  object-oriented 
software  classes  and  reusable  widgets. 

The  developmental  building  blocks  for  the  UI  software  are:  the  menu  bar  for  each  IMIS 
user  role,  the  main  presentation  associated  with  each  menu  item,  and  any  callback  routines 
associated  with  the  presentation.  Each  main  presentation  can  have  associated  additional 
presentations,  and/or  a  variety  of  widgets  associated  with  the  callback  routines  for  presentation. 
The  UI  widgets  are  implementations  of  the  UI  paradigms.  The  overall  strategy  was  to  develop 
the  main  presentations  as  fully  functional  units  with  all  the  associated  callbacks  and  to  add  each 
completed  presentation  unit  one  by  one  to  the  menu  system.  One  significant  design  constraint 
imposed  on  the  UI  was  that  it  must  work  with  the  keyboard  alone  (mouseless  navigation),  a 
pointing  device  alone  (mouse-based  navigation),  or  both.  This  constraint  was  a  key  factor  in  the 
design  of  the  UI  paradigms.  The  following  paragraphs  describe  the  various  UI  paradigms,  as 
well  as  the  UI  functionality. 
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User  Interface  Paradigms 

The  Menu  Bar  paradigm  provides  the  primary  mechanism  for  navigation  through  the 
IMIS  UI.  The  IMIS  software  utilized  a  menu  system  constructed  with  the  01  Toolkit.  A  single 
pulldown  menu  is  attached  to  each  menu  item  in  the  menu  bar.  The  menu  is  tailored  to  the  duty 
title  of  the  user  logged  in. 

Presentations  are  graphical  displays  of  class  attribute  data  created  with  the  UIB  tool. 
They  are  the  most  widely  used  of  the  UI  paradigms.  Most  menu  selections  from  the  IMIS  menu 
bar  produce  a  presentation.  Presentations  consist  of  a  set  of  display  widgets  arranged  in  the 
presentation  window,  each  of  which  is  assigned  to  a  particular  class  attribute.  At  the  base  of  each 
presentation  is  a  row  of  function  key  buttons.  These  active  function  keys  appear  with  labels 
appropriate  to  the  context  of  the  current  presentation,  such  as  '  OK,  Edit,  List,  or  Cancel. 
These  function  key  buttons  are  active  for  mouse  clicks  and  can  also  be  used  in  conjunction  with 
the  hard  function  keys  to  provide  a  mouseless  operating  environment  for  the  PMA  and  the  MIW. 

There  are  three  types  of  dialog  boxes  in  IMIS:  the  Message  Dialog  Box,  the  Respond 
Dialog  Box,  and  the  Scrolling  List  Dialog  Box.  All  dialog  boxes  in  the  IMIS  environment  are 
modal  in  nature,  that  is,  the  user  must  perform  some  action  in  the  dialog  box  before  any 
interaction  with  the  rest  of  the  UI  is  permitted.  Message  dialog  boxes  are  used  to  indicate  an 
error  condition  to  the  user  or  to  present  information  to  the  user  which  requires  an 
acknowledgment.  The  user  interacts  with  message  dialog  boxes  by  clicking  on  an  "FI  OK" 
button  to  acknowledge  the  message  presented  in  the  box.  Respond  dialog  boxes  are  used  to 
indicate  an  error  condition  to  the  user  or  to  present  information  to  the  user  in  a  situation  which 
requires  a  user  decision.  The  user  interacts  with  the  respond  dialog  box  by  clicking  on  the 
appropriate  button  (e.g.,  "FI  OK"  or  "F7  Cancel").  Scrolling  list  dialog  boxes  present  the  user 
with  a  list  of  choices  from  which  to  select.  If  the  list  is  larger  than  the  current  display,  a  scroll 
bar  appears  to  allow  the  user  to  access  the  entire  list. 

The  Entry  Selector  widget  provides  the  user  with  a  list  of  pre-defmed  choices  that  can  be 
used  to  fill  in  a  text  entry  area  in  the  UI.  The  list  may  or  may  not  scroll,  depending  on  the  size  of 
the  list.  When  the  user  has  selected  a  choice  from  the  list,  the  choice  automatically  appears  in  the 
text  entry  area.  The  Entry  Selector  is  a  modal  widget. 

The  Row-Selectable  widget  presents  a  scrolling  list  of  multi-column  data  in  a  dialog  box 
format.  The  entire  row  of  data  is  selectable  by  the  user.  This  widget  is  useful  to  display  object 
attribute  values  from  one  or  more  classes  in  the  same  row. 

The  Flierarchical  Lister  allows  navigation  through  a  list  of  nested  lists,  such  as  the  WUC 
hierarchy.  It  is  designed  to  work  like  file  selection  widgets  found  in  other  user  interfaces.  It 
appears  as  a  scrolling  list  with  a  separate  display  area  above  the  scrolling  list.  The  initial  set  of 
entries  in  the  list  is  the  top  set  of  categories  in  the  hierarchy.  As  the  user  descends  through  the 
hierarchy  of  sublists  by  pressing  "F2  Expand,"  the  current  selection  level  is  displayed  in  the 
separate  display  area.  The  lists  can  be  traversed  in  the  reverse  order  by  pressing  "F3  Collapse." 
The  Configuration  Code  widget  is  a  special  case  of  the  Hierarchical  Lister  in  which  each 
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selection  from  the  last  list  can  be  appended  to  the  Configuration  Code  being  built  in  the  separate 
display  area. 


The  Cell-Selectable  widget,  also  known  as  a  spreadsheet,  consists  of  a  two-dimensional 
matrix  of  individually  selectable  cells  which  can  be  scrolled  horizontally  and  vertically.  It  is 
used  for  applications  such  as  display  and  modification  of  flying  and  maintenance  schedules, 
where  row  data  is  logically  related  to  an  object  such  as  an  aircraft.  After  an  individual  cell  has 
been  selected,  an  operation  on  that  cell  can  be  performed  by  depressing  a  function  key  (e.g.,  edit 
cell  contents,  obtain  supplemental  information).  After  the  cell  operation  has  been  performed,  the 
cell  is  automatically  deselected. 

A  soft  keyboard  paradigm  permits  manual  editing  of  alphanumeric  entry  fields  on  the 
PMA.  This  keyboard  has  been  implemented  using  the  01  Toolkit  and  is  accessible  on  both  the 
MIW  and  PMA  via  one  of  the  function  keys. 

User  Interface  Functionality 

UI  transactions  developed  for  the  IMIS  application  covered  all  aspects  of  the  maintenance 
environment.  Only  a  subset  of  these  transactions  was  exercised  during  the  field  demonstrations 
at  Luke  AFB.  These  transactions  included  Debrief,  Open  Work  Order,  Task  Assignment,  Fighter 
Squadron  A/C  Status,  Work  Order  History,  Close  Work  Order,  Display  Flying  Schedule,  Display 
Maintenance  Schedule,  Order  Parts  (via  the  Quick  Reference  List  [QRL]  and/or  the  IPB), 
Prepare  and  Extract  PMA  Cartridge,  and  Send  and  Display  Messages.  Diagnostics  functionality 
is  discussed  in  the  section  entitled,  “Diagnostics.” 

The  Debrief  transaction  allows  the  user  to  perform  a  pilot  debrief.  The  user  enters  sortie 
and  system  capability  data,  opens  work  orders,  and  prints  out  a  sortie  recap. 

The  Open  Work  Order  transaction  allows  the  user  to  open  a  work  order  against  any  A/C 
system  or  subsystem.  IMIS  pre-fills  all  possible  data  elements  on  the  open  work  order  form. 
The  user  has  the  option  to  enter  the  FRM  to  determine  the  fault  code,  which  acts  as  an  entry  point 
into  the  diagnostics  module.  Whenever  a  work  order  is  opened,  IMIS  checks  to  see  how  it 
affects  the  A/C  status  or  if  the  entered  Estimated  Time  in  Commission  (ETIC)  exceeds  the 
current  A/C  ETIC.  Notifications  of  the  new  work  order,  as  well  as  updates  to  A/C  status,  are 
sent  to  the  appropriate  personnel. 

The  Task  Assignment  transaction  allows  a  technician  to  display  a  list  of  task  assignments 
currently  assigned  to  him/her.  The  work  order  associated  with  each  task  assignment  may  also  be 
displayed.  Maintenance  management  personnel  use  this  transaction  to  display  and  update  task 
assignment  information. 

The  Fighter  Squadron  A/C  Status  transaction  allows  the  user  to  display  the  status  of  all 
A/C  assigned  to  a  Fighter  Squadron.  The  status  displays  and  the  ability  to  alter  different  data 
elements  are  tailored  to  the  requirements  of  the  different  duty  titles.  Any  changes  to  the  data  on 
this  display  are  routed  to  the  appropriate  personnel  for  notification  and  approval. 
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The  Display  Work  Order  History  transaction  allows  the  user  to  display  all  the  closed 
work  orders  generated  over  the  previous  30  days  for  a  given  A/C  or  WUC. 

The  Close  Work  Order  transaction  allows  a  technician  to  fill  out  the  necessary  forms  to 
document  the  work  that  was  completed  on  a  work  order.  The  user  enters  the  necessary  data  into 
IMIS,  and  the  appropriate  personnel  are  notified  of  the  work  order  closure  and  resulting  A/C 
status  change,  if  necessary. 

The  Display  Flying  Schedule  transaction  allows  the  user  to  display  the  A/C  flying 
schedule  for  the  Fighter  Squadron  on  a  given  day,  including  A/C  that  are  available  as  spares. 
The  Production  Superintendent  and  Planning  and  Scheduling  personnel  are  allowed  to  update  the 
flying  schedule.  Any  changes  to  the  flying  schedule  are  routed  to  the  appropriate  personnel  for 
notification. 

The  Display  Maintenance  Schedule  transaction  allows  the  user  to  display  the  complete 
weekly  A/C  maintenance  schedule  for  the  Fighter  Squadron.  The  Production  Superintendent  and 
Planning  and  Scheduling  personnel  are  allowed  to  disregard  update  the  maintenance  schedule. 

The  Order  Parts  transaction  can  be  accomplished  through  the  QRL  or  the  IPB.  The  QRL 
contains  part  information  pertaining  to  the  IMIS  subsystems.  The  IPB  is  displayed  by  the  TO 
Presentation  (TO  Present)  and  provides  a  graphic  representation  of  the  part.  Once  a  part  has  been 
selected,  from  either  the  QRL  or  the  IPB,  the  part  order  form  is  displayed  with  complete 
information  about  the  part.  The  Production  Superintendent  is  required  to  authorize  all  part  orders 
by  entering  his  password  directly  on  the  part  order  form  or  on  a  notification  that  is  sent. 

The  Prepare  PMA  Cartridge  transaction  is  used  by  the  support  section  personnel  to 
update  the  data  contained  on  the  PMA  data  cartridge  prior  to  issuing  the  PMA  to  a  technician.  It 
presents  a  list  of  the  subsystems  (e.g.,  FCR)  for  which  diagnostics  will  be  performed.  The 
database  corresponding  to  the  selected  subsystem  is  then  copied  onto  the  cartridge  via  the  MML. 
The  Extract  PMA  Cartridge  transaction  is  used  by  the  support  personnel  when  a  technician 
returns  a  PMA  to  the  support  section  after  performing  a  maintenance  task.  It  extracts  all 
transaction  data  from  the  cartridge  and  sends  it  to  the  appropriate  sections  of  the  IMIS  and  the 
external  databases. 

The  Send  Message  transaction  allows  a  user  to  create  messages  to  be  sent  to  other  IMIS 
users.  A  user  can  input  the  destination,  subject,  and  body  of  the  message,  and  then  send  the 
message  to  other  users.  The  Display  Message  transaction  allows  a  user  to  display  any  message 
that  has  been  sent  from  other  users.  The  messages  are  display  only  and  cannot  be  updated. 

Diagnostics 

The  IMIS  Diagnostics  Module  (IMIS-DM)  assists  the  maintenance  technician  by  making 
maintenance  action  recommendations  for  diagnosing  and  repairing  a  faulty  A/C  in  minimum 
time.  In  making  its  recommendations,  IMIS-DM  considers  accrued  test  results  and  system 
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knowledge,  with  decisions  guided  by  a  pre-defined  model  of  A/C  symptoms,  faults,  tests,  and 
repairs,  created  in  accordance  with  a  customized  version  of  the  Air  Force  CDM,  version  6.0x. 
This  data  is  stored  in  and  accessed  through  the  IMIS  object  database.  All  access  to  CDM  data 
objects  by  IMIS-DM  is  Read-Only;  where  IMIS-DM  needs  to  modify  the  original  data  values 
obtained  from  CDM,  that  data  is  copied  into  local  objects  for  manipulation. 

The  IMIS-DM  architecture  includes  the  IMIS  Executive  (including  IMIS-DM),  the  task 
manager,  and  the  TO  Present  system.  Each  of  these  components  runs  in  its  own  C++  thread, 
operating  within  the  IMIS  process.  Messaging  is  used  to  pass  control  and  data  from  thread  to 
thread.  Communication  between  threads  also  takes  place  via  shared  database  objects  (in 
particular,  the  IMIS  state  table). 

The  IMIS  Executive  provides  UI  control  to  invoke  a  new  or  existing  IMIS-DM  session. 
It  also  provides  access  to  related  IMIS  functions  that  may  be  needed  during  IMIS-DM  operation, 
such  as  ordering  parts  or  displaying  messages.  IMIS-DM  analyzes  reported  and  tested  A/C 
symptoms  and  faults,  and  provides  recommendations  for  an  optimal  troubleshooting  and  repair 
sequence.  The  TO  Present  module  presents  instructions  for  performing  a  selected  task  (test  or 
repair)  and  provides  display  of  diagnostic  block  diagrams.  The  Task  Manager  provides  control 
over  IMIS-DM  and  TO  Present. 

IMIS-E)M  is  invoked  by  the  IMIS  Executive  in  response  to  the  user's  selection  of  the 
Troubleshoot"  option  on  the  menu  bar.  The  troubleshooting  request  identifies  a  target  Work 
Center  Event  (WCE)  which  provides  access  to  a  work  assignment  and  associated  discrepancy. 
The  discrepancy  object  provides  a  definition  of  the  problem  to  be  diagnosed  and  repaired,  along 
with  identification  of  the  faulty  A/C. 

IMIS-DM  initialization  involves  performing  a  number  of  queries  on  the  IMIS  object 
database  to  locate  needed  CDM  and  IMIS  information  about  applicable  faults,  tests,  symptoms, 
A/C  data,  and  user  information.  Some  up-front  loading  and  context  filtering  of  frequently 
accessed  objects  is  warranted  for  efficiency.  Given  a  target  fault  state  (based  on  the  fault  code), 
IMIS-DM  accesses  the  faults,  tests,  and  repairs  that  are  defined  for  that  fault  state.  There  is  no 
direct  link  between  a  test  and  the  faults  it  spans;  consequently,  this  processing  is  completed 
during  the  database  load  process  to  improve  the  efficiency  of  the  IMIS-DM  software. 

After  initialization  has  been  completed,  the  user  is  provided  the  opportunity  to  perform 
Aircraft  Safe  for  Maintenance  procedures  and  applicable  verification  tests.  IMIS-DM  then 
displays  a  block  diagram  of  the  subsystem  being  diagnosed,  which  can  be  used  to  see  the 
hierarchy  of  subsystems  that  could  be  the  cause  of  the  fault.  IMIS-DM  provides  a  ranked  list  of 
actions  (tests  and  repairs),  from  which  the  user  can  choose  either  the  best  (highest  ranked)  action 
or  any  other  available  test  or  repair.  When  a  test  or  repair  is  selected,  IMIS  passes  the  necessary 
information  to  the  TO  Present  system,  which  presents  the  TO  to  the  user. 

When  a  test  passes,  IMIS-DM  eliminates  any  faults  that  are  spanned  by  the  test’s  pass 
outcome,  when  a  test  fails,  each  fail  outcome  that  was  observed  yields  a  new  fault  state  that 
implicates  some  faults.  When  a  repair  is  completed,  IMIS-DM  initiates  a  system  health  check 
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that  spans  all  the  faults  which  should  be  corrected  by  that  repair.  The  user  can  continue  to 
perform  tests  and  repairs  until  all  symptoms  in  the  active  troubleshooting  group  have  been 
eliminated,  signaling  successful  completion  of  that  troubleshooting  group. 

After  clearing  all  faults,  the  user  can  perform  all  the  follow-on  actions  to  restore  the  A/C 
to  its  original  state.  The  user  can  then  close  the  work  order,  which  automatically  contains  a  list 
of  actions  taken  and  the  start  and  stop  times  of  the  diagnostics  session. 

Technical  Order  Presentation  System 

The  TO  Present  system  provides  the  means  to  interactively  display  TOs  to  the  user.  To 
provide  this  specialized  functionality  in  as  seamless  a  fashion  as  possible,  TO  Present  appears  as 
a  subprocess  within  IMIS,  with  state  information  and  certain  functions  in  higher-level 
subprocesses  accessible  within  TO  Present.  The  thread  mechanism  is  used  to  break  TO  Present 
into  subparts  which  communicate  with  each  other  and  with  IMIS. 

TO  Present  is  implemented  using  three  different  threads.  The  manager  thread  controls  all 
communication  into  and  out  of  TO  Present,  as  well  as  communication  between  the  other  two 
threads,  presentation  tasks  and  diagnostics  tasks.  Each  of  the  three  threads  has  its  own  queues, 
and  all  events  are  routed  via  the  manager  thread. 

TO  Present  operates  solely  on  COM  data  contained  in  flat  files  for  its  processing.  TO 
Present  contains  a  parser  which  reads  these  flat  files  into  an  internal  form  of  COM  which  TO 
Present  uses  in  its  display.  TO  Present  is  invoked  with  the  name  of  a  flat  file.  A  mechanism 
internal  to  TO  Present  exists  to  allow  IMIS  to  pre-process  a  flat  file  before  it  is  parsed  by  TO 
Present.  This  is  used  in  IMIS-DM  where  flat  files  are  built  on  the  fly  for  use  by  TO  Present. 
This  mechanism  also  allows  reuse  of  COM  objects  in  memory,  which  is  useful  in  speeding  up 
the  parsing  of  the  block  diagram  in  IMIS-DM. 

The  other  conduit  for  communication  between  IMIS  and  TO  Present  is  the  state  table. 
Navigation  through  a  TO  is  dependent  upon  the  user's  context  and  various  assertions  about  the 
A/C  system  to  which  the  maintenance  procedure  described  by  the  TO  applies.  A  user's  context  is 
defined  as  certain  effectivity  attributes  selected  by  the  user  and  kept  in  that  user’s  profile.  The 
assertions  pertain  to  properties  of  the  system  being  maintained,  the  user,  and  the  maintenance 
process  in  the  largest  sense  (e.g.,  history,  equipment  supplies,  and  personnel  required).  All  these 
properties  and  their  values  are  grouped  into  the  state  table.  TO  Present  reads  property  values 
from  the  state  table  and  makes  assertions  into  the  state  table  during  the  course  of  presenting  a 
TO. 


The  audit  trail  allows  access  to  information  about  which  CDM  nodes  were  visited  during 
a  TO  Present  traversal.  IMIS  uses  this  information  during  an  IMIS-DM  session  to  determine 
which  tasks  the  user  has  accessed. 
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Message  Manager 


For  personnel  using  IMIS  to  make  accurate  and  informed  decisions  regarding  their 
assigned  maintenance  tasks,  it  is  critical  to  have  reliable  and  consistent  process-to-process 
communication.  The  Message  Manager  is  responsible  for  maintaining  consistency  between  the 
MIW  shared  database  and  the  PMA  local  databases.  The  Message  Manager  also  sends  updates 
to  the  MML  copy  of  the  shared  database,  which  is  used  for  downloading  memory  modules.  The 
Message  Manager  operates  over  the  RF  link  and  over  the  network. 

IMIS  data  is  either  read-write  data,  Read-Only  data,  or  data  local  to  the  process.  Certain 
instances  of  the  IMIS  class  library ,  EDM  class  library.  System  class  library,  and  Diagnostics 
class  library  are  read-write  data.  The  Message  Manager  must  keep  the  read-write  data  consistent 
across  all  databases  and  platforms.  Every  change  to  read-write  data  is  recorded  in  the  database 
and  reported  to  the  message  manager,  which  then  sends  the  transaction  to  all  appropriate 
databases  for  update. 

The  Message  Manager  is  also  responsible  for  the  decomposition  of  an  object  into  a  byte 
stream  and  the  recomposition  of  the  byte  stream  into  an  object  for  communication.  The  byte 
stream  is  sent  from  one  database  to  another  over  the  RF  link  or  over  the  network.  The  following 
paragraphs  describe  the  Message  Manager  operations  on  the  PMA  and  on  the  MIW. 

PMA  Message  Manager 

On  the  PMA,  a  buffer  exists  between  IMIS  and  the  Message  Manager  to  hold  the 
outgoing  requests  and  the  incoming  responses.  Requests  remain  in  the  buffer  until  the 
corresponding  responses  are  received.  If  the  RF  communication  is  off  or  out  of  range,  the 
requests  will  remain  in  the  buffer  until  RF  communication  is  possible  or  the  memory  module  is 
uploaded  in  the  MML.  The  PMA  Message  Manager  uses  the  RF  link  to  communicate  with  the 
MIW.  Requests  from  IMIS  are  sent  out  as  messages  over  the  RF  link.  The  PMA  Message 
Manager  will  remain  active,  trying  to  receive  a  response  to  the  request,  for  a  configurable  time 
limit. 


The  PMA  Message  Manager  places  responses  in  the  buffer  for  IMIS  to  receive.  It  also 
informs  the  user  of  the  use  of  the  RF  link  and  any  of  the  following  errors:  inability  to  transmit  to 
the  MIW,  no  response  received  from  the  MIW,  and  abort  received  from  the  MIW  in  response  to  a 
request  for  change  from  the  PMA. 

There  are  three  categories  of  remote  requests  which  are  handled  by  the  PMA  Message 
Manager:  change  request,  data  request,  and  update  request.  A  change  request  allows  changes  to 
the  PMA  local  database  to  be  repeated  on  the  MIW  shared  database  by  the  receiving  MIW 
Message  Manager.  The  MIW  Message  Manager  responds  with  a  confirmation  if  the  change  was 
completed  or  an  abort  if  the  change  could  not  be  performed  on  the  shared  database.  An  abort 
condition  can  occur  if  a  user  on  another  PMA  or  MIW  has  changed  the  database  first. 
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A  data  request  seeks  data  from  the  shared  database.  The  MIW  Message  Manager 
responds  with  the  requested  data  if  it  can  be  obtained  from  the  MIW  shared  database  or  with  a 
response  that  the  requested  data  was  not  found.  The  requested  data  will  then  be  stored  in  the 
local  database. 

An  update  request  asks  the  MIW  Message  Manager  to  transfer  the  queued  updates  for  the 
local  database  to  the  PMA.  The  MIW  Message  Manager  will  transmit  all  the  updates  which  have 
been  queued  for  the  PMA’s  particular  local  database.  The  updates  will  then  be  performed  on  the 

local  database. 

MIW  Message  Manager 

The  MIW  Message  Manager  handles  the  requests  of  each  PMA  and  manages  the  updates 
which  must  be  queued  for  each  PMA  local  database  until  they  are  requested.  The  Message 
Manager  also  queues  the  updates  for  the  MML  copy  of  the  shared  database.  Modifications  to  the 
shared  database  by  MIW  IMIS,  EDM,  and  the  Data  Module  Loader  process  also  need  to  be 
written  to  the  PMA  local  databases  through  Message  Manager  updates.  The  modifications  are 
written  to  a  buffer  and  read  by  the  MIW  Message  Manager,  which  determines  which  PMAs  need 
to  receive  the  update  based  on  the  list  of  "checked  out  PMAs. 

When  the  IMIS  process  on  the  MIW  (or  the  EDM  process)  makes  a  change  to  the  shared 
database,  an  update  is  also  written  which  can  be  used  to  re-create  the  same  changes  on  the  local 
database' on  each  PMA  and  the  MML.  The  update  is  read  in  by  the  MIW  Message  Manager, 
which  determines  which  PMAs  the  change  needs  to  be  sent  to.  The  updates  are  stored  until  they 
are  requested  by  the  PMA  over  the  RF  link  or  the  PMA  is  checked  in.  Similarly,  when  the  IMIS 
process  on  the  MIW  creates  a  message  to  be  sent  to  another  user,  the  MIW  Message  Manager 
reads  in  the  message  and  follows  the  same  process. 

The  MIW  Message  Manager  must  also  handle  the  three  types  of  remote  user  requests 
described  in  the  preceding  section:  change  request,  data  request,  and  update  request.  In  the  case 
of  the  change  request,  the  MIW  Message  Manager  will  perform  the  change  on  the  shared 
database  (sending  an  abort  response  to  the  PMA  if  the  update  was  unsuccessful),  determine 
which  PMAs  need  to  receive  the  update,  and  write  out  the  update  to  buffers  for  each  of  those 
PMAs.  The  updates  are  stored  until  they  are  requested  by  the  PMA  over  the  RF  link  or  the  PMA 
is  checked  in.  The  MIW  Message  Manager  handles  the  PMA  update  requests  by  getting  the 
queue  of  updates  for  that  PMA  and  transmitting  the  updates  across  the  RF  link.  The  MIW 
Message  Manager  responds  to  the  PMA  data  requests  with  the  requested  data,  if  available,  or 
with  an  error  response  if  the  request  could  not  be  fulfilled. 


External  Data  Management 


The  EDM  interface  runs  on  the  MIW  and  serves  as  the  interface  between  the  IMIS  object 
database  and  CAMS,  the  legacy  system.  The  main  function  of  the  EDM  interface  is  to  maintain 
consistency  between  IMIS  and  CAMS.  User-induced  changes  to  IMIS  data  which  is  also 
resident  in  CAMS  must  be  made  to  CAMS,  and  data  from  CAMS  or  SBSS  must  be  retrieved 
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periodically  for  display  to  the  IMIS  user.  The  IMIS  object  database  is  initialized  with  data 
needed  from  CAMS;  thereafter,  consistency  is  maintained  with  batch  scheduled  updates. 

EDM  uses  the  Sybase  Structured  Query  Language  (SQL)  server  as  an  intermediate  data 
repository  to  provide  a  vehicle  for  communication  between  the  object-oriented  IMIS  application 
and  the  screen-oriented  CAMS  application.  This  architecture  allows  for  extensions  to  other 
external  databases  in  the  future  with  minimal  impact  on  existing  IMIS  software. 

When  IMIS  objects  which  have  attributes  tracked  in  CAMS  are  created  or  updated,  a 
process  to  transfer  this  data  to  Sybase  is  initiated.  From  the  IMIS  perspective,  the  flow  of  data 
between  IMIS  and  CAMS  is  accomplished  by  procedures  which  add  rows  to  Sybase  tables  (to 
send  data  to  CAMS)  or  which  copy  rows  from  Sybase  tables  (to  get  data  from  CAMS). 

There  are  four  types  of  Sybase  tables:  shared  data  tables  corresponding  to  IMIS  classes,  a 
control  table  to  support  the  communication  protocol  between  the  IMIS  and  CAMS  interface 
processes,  tables  used  for  administrative  purposes,  and  CAMS  data  tables. 

Each  Sybase  shared  data  table  corresponds  to  an  IMIS  class,  each  row  relates  to  an 
instance  of  an  IMIS  object  and  each  column  relates  to  an  attribute  of  an  IMIS  object.  Each  table 
name  is  identical  to  the  name  of  its  class  counterpart.  The  data  contained  in  these  shared  tables  is 
transitory,  remaining  only  until  it  has  been  processed. 

When  IMIS  requires  CAMS  data  or  must  send  data  to  CAMS,  an  entry  to  the  ONTOS 
EDM  Service  queue  is  added.  The  entry  on  this  first-in,  first-out  ordered  queue  is  read  and  sent 
to  the  EDM  control  table,  specifying  the  information  necessary  for  the  CAMS  server  process  to 
service  the  request.  The  CAMS  process  satisfies  these  request  by  either  retrieving  one  or  more 
data  tables  to  send  to  CAMS,  or  adding  data  to  one  or  more  data  tables  to  send  to  IMIS. 

The  Sybase  CAMS  data  tables  permanently  store  data  sent  to  or  received  from  CAMS 
and  SBSS  (unlike  the  shared  tables,  which  are  transitory).  These  tables  are  automatically 
updated  periodically  so  that  IMIS  does  not  normally  need  to  wait  for  an  actual  query  to  CAMS 
data  to  be  completed. 

Once  a  request  for  data  has  been  placed  in  the  control  table,  the  Extract  Queue  Manager,  a 
stand-alone  process  that  is  invoked  at  regular  intervals,  extracts  data  from  Sybase,  builds  a  fixed- 
format,  variable-length  record  corresponding  to  the  request  type,  and  inserts  that  record  into  the 
transaction  queue.  The  Transaction  Control  module  reads  the  transaction  queue,  determines  the 
screen  number  related  to  the  current  queue  record,  and  retrieves  the  screen  template  and  field 
format  of  the  CAMS  screen.  The  Communications  Interface,  which  consists  of  a  screen  handler 
and  a  communications  handler,  then  communicates  with  the  Uniscope  terminal  port  and  CAMS. 
The  screen  handler  allows  the  emulation  of  a  Uniscope  terminal  on  a  Sun  workstation.  To  send 
data  to  CAMS,  the  input  screen  buffer  is  first  updated  to  reflect  the  correct  field  positions  for  a 
specific  CAMS  screen,  then  the  communications  handler  sends  the  screen  to  CAMS.  If  the 
transaction  sent  to  CAMS  is  a  query,  the  output  buffer  that  was  processed  will  return  data  to  be 
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passed  back  to  IMIS.  The  Update  Queue  Manager  will  then  extract  this  data  and  insert  it  into  the 
appropriate  Sybase  tables. 

The  CAMS  interface  transaction  types  which  have  been  fully  tested  include:  Send 
Flightline  Open  Work  Order,  Send  Debrief  Open  Work  Order,  Get  Open  Work  Orders  from 
CAMS,  Send  Closed  WCE  to  CAMS,  Get  Closed  Work  Orders  from  CAMS,  Send  Sortie 
Debrief,  Get  Fighter  Squadron  Sorties  from  CAMS,  Get  Certification  Roster  from  CAMS,  Get 
Part  Inventory,  and  Send  Part  Order  to  SBSS.  In  addition,  other  transactions  which  were 
implemented  but  not  fully  tested  during  the  IMIS  demonstrations  include:  Send  Opened  WCE  to 
CAMS,  Send  Updated  WCE  to  CAMS,  Send  Cancel  Back  Order  to  SBSS,  Get  Back  Ordered 
Parts  Status  from  SBSS,  Send  Back  Order  Part  Request  to  SBSS,  and  Get  Scheduled  Work  Order 
from  CAMS  (Maintenance  Schedule). 

PMA-Unique  Software 

The  IMIS  software  was  designed  so  that  the  hardware  platform  on  which  a  user  was 
executing  the  application  would  have  minimal  impact  on  the  available  functionality.  Some 
software,  however,  had  to  be  developed  specifically  for  the  PM  A,  due  to  the  unique  capabilities 
required  for  that  platform.  In  particular,  it  was  critical  to  develop  the  ability  for  the  PMA  to 
interface  with  the  A/C  1553  bus,  allowing  the  user  to  initiate  Built-In-Test  (BIT)  on  the  three 
demonstration  subsystems  and  view  the  results. 

Since  SCO  Unix  does  not  incorporate  a  real-time  pre-emptible  kernel,  user  access  to 
hardware  devices  (e.g.,  the  1553  module  on  the  PMA)  is  restricted.  To  provide  access  to  these 
hardware  devices,  it  is  necessary  to  create  a  device  driver  which  is  linked  with  and  becomes  part 
of  the  operating  system  executable  kernel.  The  1553  device  driver  consists  of  routines  that 
initialize  the  device  for  use,  prepare  the  device  for  shutdovm,  open  the  device  for  use,  close  the 
device  (thereby  prohibiting  further  access),  perform  device-specific  control  commands,  and 
perform  interrupt  servicing  whenever  the  device  generates  an  interrupt. 


SYSTEM  INTEGRATION 

To  ensure  that  the  IMIS  demonstration  system  was  capable  of  supporting  the  field  test 
and  demonstration  activities,  all  aspects  of  the  system,  including  hardware  and  software,  were 
tested.  The  following  subsections  describe  the  testing  conducted  for  the  hardware,  software,  and 
system  prior  to  installation  at  Luke  AFB  for  the  various  field  tests  and  demonstrations. 

Hardware  Testing 

Prior  to  the  Hardware  CDR,  hardware  testing  was  conducted  in  accordance  with  the 
procedures  defined  in  the  Contractor  Test  Plan,  CDRL  25.  Limited  environmental  tests  were 
performed  on  the  80386  PMA  only;  the  MIW  used  COTS  components,  and  the  AIP  design  was 
similar  to  the  PMA,  allowing  comparisons  to  the  PMA  testing  results  to  be  made.  The  testing 
performed  is  discussed  in  the  following  subsections. 
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PMA  Weight  and  Dimension  Test 


This  test  was  eonducted  to  determine  if  the  weight  and  size  of  the  PMA  met  the 
speeifications.  The  PMA  was  weighed  on  a  calibrated  scale  with  the  strap  removed  and  without 
the  1553B  interface  circuitry  installed.  The  PMA  was  then  measured  with  a  caliper  to  determine 
its  length,  width,  and  height.  The  weight  of  the  PMA,  excluding  the  strap,  handle,  and  1553B 
interface  circuitry,  was  3.21  kilograms  (7.06  pounds).  The  weight  of  the  1553B  module  is 
approximately  0.04  kilograms  (0.1  pounds),  for  a  total  of  3.25  kilograms  (7.16  pounds).  The 
PMA  dimensions,  exclusive  of  the  handle,  RF  antenna,  disk  drive  cover,  and  1553  port 
protective  caps,  were  measured  to  be  31.1  x  25.4  x  5.7  centimeters  (12.25  x  10.00  x  2.25  inches). 

PMA  Environmental  Tests 

A  series  of  environmental  tests  were  performed  in  accordance  with  MIL-STD-810, 
tailored  as  appropriate,  to  determine  the  PMA’s  ability  to  withstand  various  environmental 
conditions.  These  included  temperature/humidity,  altitude,  vibration,  shock,  water  resistance, 
and  explosive  atmosphere. 

The  temperature/humidity  test  was  conducted  to  determine  if  the  PMA  would  operate 
properly  after  being  stored  at  its  minimum  (-20°C)  and  maximum  (40°C)  storage  temperatures 
and  also  throughout  its  operating  temperature  range  of  5°C  to  40°C  under  conditions  of  varying 
relative  humidity  (from  25%  to  80%).  The  PMA  operated  satisfactorily  during  exposure  to  the 
operational  temperature/humidity  limits  and  following  exposure  to  the  storage  limits.  At  each 
test  point,  the  PMA  operational  test  routine  was  successfully  completed. 

The  altitude  test  was  conducted  to  determine  if  the  PMA  would  operate  properly  after 
being  exposed  to  its  non-operating  altitude  limit  of  4572  meters  (15,000  feet)  and  at  its  operating 
altitude  limit  of  3048  meters  (10,000  feet).  The  PMA  operated  satisfactorily  following  exposure 
to  its  non-operating  altitude  limit  of  4572  meters  and  operated  satisfactorily  at  an  altitude  of  3048 
meters. 


The  vibration  test  was  conducted  to  determine  if  the  PMA  would  be  damaged  by 
vibration  in  any  of  its  three  axes  between  5  Hertz  (Hz)  and  55  Hz.  In  the  vertical  and  transverse 
axes,  both  the  handle  and  RE  antenna  resonated  from  46  Hz  to  55  Hz.  The  peak-to-peak 
amplitude  of  vibration  was  0.25  to  0.375  inches  (0.635  to  0.95  centimeters).  A  resonance  dwell 
was  performed  at  46  Hz  in  the  transverse  axis,  and  no  increase  in  amplitude  was  noted  during  the 
10-minute  dwell.  In  the  vertical  axis,  a  slight  resonance  was  found  in  the  inverter  at  52  Hz.  An 
accelerometer  was  attached  to  the  point  of  greatest  displacement,  and  a  resonance  dwell  was 
conducted  at  52  Hz.  The  accelerometer  measured  a  g-force  of  2.2  g  when  the  table  g-force 
measured  1.9  g.  This  was  not  considered  a  significant  increase  and  therefore  not  noted  as  a 
resonance.  There  was  no  degradation  of  either  equipment  or  performance  during  these  dwell 
tests.  No  resonances  were  observed  for  the  longitudinal  axis. 
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The  shock  test  was  conducted  to  measure  the  ability  of  the  PMA  to  withstand  shocks 
liable  to  occur  during  use  or  servicing.  Using  one  edge  as  a  pivot,  the  opposite  edge  was  raised 
four  inches  above  the  horizontal  bench  top  and  dropped.  The  PMA  met  all  bench-handling 
requirements.  There  was  no  physical  damage  noted  concerning  the  case  and  the  operating 
performance  was  consistent  with  normal  operations. 

The  water-resistance  test  was  conducted  to  determine  the  ability  of  the  PMA  to  function 
properly  after  being  subjected  to  a  drip-proof  test.  The  requirements  for  water  flow  were  16.3 
liters  per  hour  for  each  square  foot  (0.09  square  meters)  of  area  covered  by  the  spray  0.9  meters 
below  the  nozzle.  The  initial  water  resistance  test  of  the  PMA  failed  because  some  moisture  was 
found  inside  the  case  upon  opening.  The  cause  of  this  problem  was  loose  connections  at  the 
connector  panel.  After  tightening  the  hold-down  hardware,  the  test  was  repeated.  The  PMA 
operational  test  was  successfully  completed,  and  no  moisture  was  found  inside  the  case  upon 
opening. 


The  explosive  atmosphere  test  was  conducted  at  Wyle  Laboratories  test  facility  to 
evaluate  the  ability  of  the  PMA  to  operate  in  a  fuel-vapor-laden  environment  without  igniting 
that  environment.  The  PMA  operated  satisfactorily  when  subjected  to  an  explosive  atmosphere. 
No  detonations  occurred  upon  the  activation  of  any  button  or  switch. 

PMA  Interface  Tests 

A  series  of  three  tests  was  conducted  to  determine  whether  the  PMA  interfaces  operated 
correctly.  These  included  the  Memory  Module,  the  RF  Module,  and  the  battery. 

The  Memory  Module  test  was  conducted  to  demonstrate  the  ability  to  transfer  and  store 
data  via  the  Memory  Module.  These  abilities  were  verified  by  the  test. 

The  RF  Module  test  was  conducted  at  Edwards  AFB  to  demonstrate  the  capability  to 
communicate  between  a  hand  held  PMA  and  a  fixed-site  MIW  by  transmitting  and  receiving  data 
via  an  RF  link.  The  ability  to  transfer  data  via  the  RF  link  was  verified.  During  this  test,  the 
ability  to  transmit  and  receive  data  at  each  required  distance  when  in  direct  line-of-sight  of  the 
receiving  antenna  was  demonstrated.  The  maximum  range  verified  under  line-of-sight 
conditions  was  3500  feet  (1067  meters).  The  maximum  range  verified  with  the  line-of-sight 
interrupted  by  various  obstructions  was  2000  feet  (610  meters). 

The  battery  test  was  conducted  to  verify  the  PMA’s  ability  operate  from  either  a 
rechargeable  battery  or  an  external  power  source.  The  PMA  operational  test  was  successfully 
completed  when  operating  with  either  the  external  power  source  or  the  battery  pack.  There  was 
no  degradation  of  performance  noticed  when  using  either  of  the  power  sources. 

PMA  Electromagnetic  Radiation  Test 

This  test  was  conducted  to  determine  the  level  of  radiation  emanating  fi*om  the  PMA  and 
also  to  determine  how  susceptible  the  PMA  is  to  a  radiated  field.  The  PMA  passed  all  testing 
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requirements  as  determined  by  MIL-STD-461C,  Part  2:  Requirements  for  Equipment  and 
Subsystems  Installed  Aboard  Aircraft,  Including  Associated  Ground  Support  Equipment  (Class 
Al).  The  test  methods  performed  were  RE02  for  radiated  emissions  and  RS03  for  radiated 
susceptibility.  All  measurements  taken  were  well  within  defined  limits,  except  when  performing 
the  susceptibility  test  at  the  transmitting  and  receiving  frequencies  of  900  to  910  MHz.  At  these 
fundamental  frequencies,  the  PMA  RF  module  would  not  function,  even  when  subjected  to 
energy  levels  of  only  0.5  volts  per  meter.  This  was  expected,  due  to  the  sensitivity  of  the  RF 
Module  in  the  PMA.  The  fundamental  transmitting  and  receiving  frequencies  of  the  PMA 
should  be  exempt  from  meeting  the  RS03  requirement. 

Software  Testing 

The  software  testing  performed  to  support  system  integration  has  been  broken  down  into 
the  five  main  functional  areas  of  the  software:  UI,  Diagnostics,  EDM,  PMA  Software,  and 
Message  Manager.  Due  to  the  dynamic  nature  of  the  software  development  process,  the  testing 
as  described  in  the  following  subsections  was  repeated  whenever  conditions  existed  that  could 
affect  the  performance  of  the  software  that  had  worked  correctly  at  one  time.  This  could  be  the 
result  of  a  database  change,  in  the  case  of  the  diagnostics  testing,  or  as  a  result  of  a  change  to 
CAMS,  in  the  case  of  the  EDM  testing. 

User  Interface  Testing 

The  UI  testing  focused  on  the  correct  behavior  of  the  software  from  the  user  perspective. 
Checklists  were  developed  to  document  the  expected  software  functionality  and  to  record  any 
deviations  observed.  These  checklists  covered  each  of  the  functions  accessible  from  the  IMIS 
main  menu  bar  and  were  conducted  in  order  to  simulate  realistic  conditions  when  possible. 
Testing  was  conducted  on  both  the  MIW  and  PMA  platforms  and  was  repeated  each  time  a  new 
software  release  was  created.  Elapsed  time  measurements  were  also  gathered  when  utilizing 
these  checklists,  to  allow  identification  of  functions  where  software  enhancements  were 
necessary. 

Diagnostics  Testing 

Because  of  the  dependencies  of  the  diagnostics  software  and  the  authored  TO  data,  the 
diagnostics  testing  included  significant  amounts  of  data  testing.  The  problems  found  first  had  to 
be  analyzed  to  determine  whether  they  were  caused  by  software  or  by  data.  To  support  this 
complicated  process,  two  types  of  diagnostics  testing  were  performed:  path  testing  and  numeric 
testing.  The  path  testing  served  as  a  check  of  all  the  data  used  during  the  Fault  Isolation  Test  to 
ensure  that  the  correct  recommendations  for  best  action  were  made  by  the  diagnostics  algorithms, 
that  the  data  was  displayed  in  the  proper  sequence,  and  that  the  necessary  ancillary  information 
(such  as  required  conditions,  follow-on  tasks,  and  block  diagram)  was  updated  to  correctly  reflect 
any  new  actions  taken.  The  numeric  testing  examined  the  weights  and  probabilities  authored  in 
the  TO  data  to  ensure  they  were  correctly  processed  through  the  diagnostics  algorithms.  Again, 
the  focus  was  on  the  data  that  was  exercised  during  the  Fault  Isolation  Test.  As  new  data 
deliveries  were  received,  this  testing  was  repeated. 
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External  Data  Management  Testing 

The  EDM  testing  verified  the  interactions  between  the  ONTOS  database,  the  Sybase 
database,  and  CAMS.  This  integration  testing  was  complicated  for  two  reasons:  the  software 
was  developed  by  two  different  organizations  (GDE  Systems  and  SCT),  and,  as  frequent  changes 
were  made  to  the  CAMS  system,  the  EDM  software  had  to  be  changed.  The  CAMS  transactions 
were  analyzed  for  applicability  to  each  field  test  and  prioritized  accordingly.  The  entire  process 
for  each  transaction  was  tested,  beginning  with  the  action  at  the  UI  level,  storing  the  data  in  the 
Sybase  database,  transmitting  the  data  to  CAMS,  and  verifying  that  the  data  was  correctly  stored 
in  CAMS.  Responses  received  from  CAMS  and  SBSS  were  also  verified.  This  testing  was 
repeated  for  each  new  CAMS  release  that  was  installed. 

PMA  Software  Testing 

The  PMA  software  testing  verified  the  capability  of  all  PMA-unique  software  modules, 
as  described  in  the  subsection  entitled,  “PMA-unique  software.”  The  primary  PMA  software 
testing  was  in  the  area  of  the  1553  interface.  Testing  to  ensure  that  the  software  would  initiate 
BIT  on  the  applicable  1553  MUX  buses  and  retrieve  the  results  had  to  be  conducted  on  the  A/C. 
The  testing  was  conducted  at  both  Edwards  AFB  and  at  Luke  AFB. 

Message  Manager  Testing 

The  Message  Manager  testing  verified  the  capability  to  disseminate  information  between 
system  users  and  to  ensure  that  all  databases  remained  consistent.  This  testing  began  on  the 
MIW  to  test  the  basic  message-handling  fimctions.  As  the  RF  drivers  for  both  the  PMA  and  the 
MIW  became  available,  this  testing  migrated  to  a  multi-platform  environment.  MIW-to-PMA 
and  PMA-to-MlW  communications  using  the  RF  link  were  thoroughly  tested  to  ensure  that  data 
and  messages  were  correctly  and  reliably  transmitted  throughout  the  system.  The  final  phase  in 
the  Message  Manager  testing  was  the  testing  of  multiple  PMAs  and  MIWs  to  support  the  various 
field  tests  and  demonstrations. 

System  Testing 

Prior  to  the  CDR,  system  testing  was  informally  controlled.  Systems  Engineering, 
Human  Factors,  and  the  Maintenance  Subject  Matter  Expert  were  involved  in  the  testing  to 
ensure  early  compliance  with  requirements  and  to  ensure  Ul  issues  were  addressed  and 
incorporated  during  the  implementation  stages.  This  policy  was  designed  to  ensure  the  accuracy 
of  the  IMIS  representation  of  the  maintenance  environment,  as  well  as  to  ensure  the  system’s 
user  friendliness.  This  not  only  provided  the  ability  to  recommend  system  changes  early  but  also 
increased  the  likelihood  of  user  acceptance. 

After  CDR,  system  testing  was  organized  around  the  software  builds  and  was  more 
formally  controlled.  All  discrepancies  were  documented  on  Discrepancy  Reports  (DRs)  and 
reviewed  by  the  Discrepancy  Review  Board,  which  was  composed  of  representatives  from 


49 


Systems  and  Software  Engineering,  Human  Factors,  and  Maintenance.  The  Chief  Engineer 
chaired  the  board.  The  board  reviewed  all  discrepancies  and  assigned  each  DR  a  priority  within 
a  particular  build.  Assignments  were  made  to  the  corresponding  focus  area  for  resolution.  Once 
the  DRs  were  fixed,  they  were  verified  by  Systems  Engineering  and  submitted  to  the  Chief 
Engineer  for  closure.  Matrices  were  generated  on  a  weekly  basis  to  keep  track  of  all  DRs  and  to 
monitor  status. 

System  testing  focused  initially  on  the  engineering  environment.  As  the  field  tests  and 
demonstrations  approached,  the  need  to  conduct  realistic  testing  in  the  demonstration 
environment  was  recognized.  As  a  result,  significant  testing  was  performed  at  Luke  AFB  prior 
to  each  test  or  demonstration  to  ensure  the  correct  functioning  of  the  system.  Detailed 
procedures,  based  on  the  requirements  for  the  test,  were  developed  and  exercised  to  verify  that  all 
components  of  the  system  interacted  correctly.  After  sufficient  testing  of  the  hardware,  software, 
and  data  had  taken  place  and  the  necessary  dry  runs  of  the  demonstration  activities  had  been 
successfully  completed,  the  field  test  was  begun. 


FIELD  TEST  AND  DEMONSTRATION  OVERVIEW 

The  IMIS  Field  Test  and  Demonstration  was  separated  into  three  segments:  Debrief  Test, 
End-to-End  Demonstration,  and  Fault  Isolation  Test.  The  primary  objectives  of  these  activities 
were:  to  test  the  IMIS  concept  under  realistic  operational  conditions  where  possible,  to  evaluate 
the  effectiveness  of  IMIS  in  supporting  the  maintenance  mission  of  the  unit,  to  demonstrate  the 
technical  and  cost  advantages  of  IMIS  over  the  current  system,  and  to  identify  strengths  and 
weaknesses  of  the  demonstration  system  which  could  be  used  in  defining  requirements  for  a 
production  implementation.  The  following  sections  describe  the  objectives  and  methodology  of 
each  of  these  tests. 


Debrief  Test 

The  Debrief  Test  was  the  first  of  the  three  field  tests  and  evaluations  of  the  IMIS 
demonstration  system  conducted  at  Luke  AFB,  AZ.  Real  debriefs  were  observed  during  a  six- 
week  period  in  November  and  December  1993  to  compare  the  current  method  of  debriefing  to 
that  using  IMIS. 

Objectives 

The  primary  objective  of  the  Debrief  Test  was  to  evaluate  the  IMIS  debrief  capability 
under  realistic  conditions  by  observing  actual  maintenance  debriefs  of  pilots  and  by  collecting 
data  to  compare  the  results  of  debriefs  performed  using  IMIS  with  those  performed  using  the 
current  method.  Specifically,  the  following  hypotheses  were  tested  using  the  data  collected 
during  the  Debrief  Test. 

a.  Significantly  more  discrepancies  are  identified  when  the  debrief  is  conducted  using  IMIS 
than  when  the  debrief  is  performed  using  the  current  system. 
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b.  Significantly  less  time  is  required  when  the  debrief  is  performed  using  IMIS  than  when  it 
is  performed  using  the  current  system. 

c.  Debriefs  performed  using  IMIS  describe  discrepancies  in  greater  detail  than  debriefs 
performed  using  the  current  method  (e.g.,  using  IMIS,  Maintenance  Fault  Lists  (MFLs) 
and  the  resulting  fault  codes  are  more  specific  and  further  narrow  the  scope  of  the 
diagnostics  required). 

d.  Maintenance  debriefers  will  prefer  the  IMIS  debrief  method  to  the  current  debrief  method. 
Methodology 

The  Debrief  Test  was  accomplished  by  observing  and  timing  a  relatively  large  number  of 
actual  debrief  sessions,  half  using  IMIS  and  half  using  the  current  method.  The  maintenance 
debrief  process  is  performed  by  a  technician  at  a  CAMS  terminal,  with  one  or  more  F-16  pilots 
seated  across  a  low  counter  from  the  technician.  The  pilots  hand  their  data  transfer  cartridge 
(DTC)  to  the  maintenance  debriefer  and  provide  their  flight  data,  subsystem  usage,  capability 
codes,  and  discrepancy  information  as  well,  partly  spontaneously  and  partly  in  response  to  the 
debriefers  questions.  During  this  process,  the  debriefer  places  each  DTC  in  the  DTC  reader, 
downloads  the  MFL  file,  and  returns  the  DTC  to  the  pilot.  The  debriefer  may  interact  with  one 
or  more  of  the  pilots,  may  input  information  directly  into  CAMS,  or  may  write  it  down  for  later 
entry.  The  debriefer  will  endeavor  to  delay  each  pilot’s  departure  from  the  debriefing  area  as 
little  as  possible.  Once  the  pilots  have  left  the  debriefing  station,  the  debriefer  enters  into  the 
CAMS  terminal  any  flight  and  discrepancy  data  written  by  hand,  opening  work  orders,  as 
appropriate. 

The  IMIS  debrief  sessions  were  performed  using  an  IMIS  MIW  located  in  the 
maintenance  debriefing  section.  After  reading  and  returning  the  DTC  to  the  pilot,  the 
maintenance  debriefer  asked  the  pilot  questions  about  the  flight  and  any  A/C  discrepancies.  The 
IMIS  debrief  included  an  automated  implementation  of  the  F-16  FRM,  a  list  of  other  standard 
narratives  of  discrepancies  in  each  subsystem  and  a  set  of  weapon  system  peculiar  questions 
(enhanced  question  set).  Use  of  the  FRM  and  enhanced  question  set  enabled  IMIS  to  translate 
the  reported  discrepancy  directly  into  a  fault  code.  The  fault  code  will  lead  the  technician  to  the 
correct  path  in  diagnosing  the  problem.  After  opening  all  work  orders,  the  maintenance  debriefer 
reviewed  and  printed  the  Sortie  Recap.  IMIS  then  queued  the  sortie  and  work  order  data  for 
transmittal  to  CAMS,  which  was  done  in  the  background  without  inconvenience  to  or 
involvement  of  the  IMIS  debriefer,  regardless  of  whether  CAMS  was  operational  at  that  moment. 

The  Debrief  Test  was  conducted  by  observing  and  recording  data  (including  start  and 
stop  times,  problems  encountered,  and  any  other  observations  or  remarks)  during  each  pilot 
debrief  session.  Information  collected  about  each  discrepancy  included  the  WUC,  whether  the 
pilot  provided  any  amplifying  data  about  the  discrepancy,  and  the  Job  Control  Number  of  the 
work  order  opened  to  correct  the  discrepancy. 
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After  completion  of  the  debrief  session,  a  data  collector  tracked  all  reported  discrepancies 
through  the  maintenance  system  to  determine  what  maintenance  actions,  if  any,  were  taken  to 
correct  each  one  and  which  turned  out  to  be  CNDs  or  RTOKs.  At  the  end  of  the  Debrief  Test, 
the  maintenance  debriefers  were  asked  to  complete  two  questionnaires  soliciting  their  evaluation 
of  the  system  and  recommendations  for  changes  or  improvements. 

End-to-End  Demonstration 

The  End-to-End  Demonstration  was  a  field  demonstration  of  the  primary  functions  of 
IMIS.  The  overall  scenario  used  for  the  End-to-End  Demonstration  is  depicted  in  Figure  11. 
This  demonstration  was  conducted  at  Luke  AFB,  AZ,  from  1  June  through  30  June  1994.  The 
purpose  was  to  illustrate  to  users  the  overall  IMIS  concept  by  using  the  system  to  support  a  series 
of  typical  scenarios  of  maintenance  activities  in  an  operational  environment,  under  structured 
conditions.  It  demonstrated  system  functional  capabilities  in  all  primary  IMIS  functional  areas: 
debrief,  diagnostics,  electronic  TOs,  work  order  generation  and  close-out,  and  flightline 
management  support. 

Objectives 

The  principal  objectives  of  the  End-to-End  Demonstration  were  as  follows. 

a.  To  test  the  overall  IMIS  concept  by  exercising  IMIS  capabilities  in  all  primary  (e.g., 
debrief,  diagnostics,  etc.)  functional  areas  by  demonstrating  a  limited  set  of  functions 
within  each  area. 

b.  To  obtain  user  feedback  in  each  primary  functional  area.  This  feedback  could  provide 
information  for  use  in  identifying  candidate  changes/improvements  for  a  fully 
implemented  IMIS. 

c.  To  provide  an  opportunity  for  the  IMIS  team  members  to  observe  the  system  in  operation 
under  conditions  approaching  those  in  the  real  world  of  A/C  maintenance,  to  aid  them  in 
identifying  changes/improvements  needed  in  a  fully  implemented  IMIS. 

Methodology 

Scenarios  demonstrating  the  maintenance  functionality  were  developed  for  the  production 
superintendent,  airplane  general  (APG)  expediter,  specialist  expediter,  debriefer,  and 
maintenance  technician.  These  scenarios  required  each  participant  to  perform  a  series  of  tasks 
using  IMIS.  The  actions  were  designed  to  cause  the  participant  to  exercise  those  functions 
available  in  IMIS  to  do  their  assigned  tasks.  For  example,  the  specialist  expediter  received  a 
work  order  through  IMIS  and  was  required  to  assign  a  technician  to  the  job.  Similarly,  the 
production  superintendent  received  a  request  for  authorization  to  order  a  part,  and  was  required 
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SUPPORT  SECTION 
LOGS  ON  MIWAND 
PREPARES 

CARTRIDGES  FOR  ONE 
APG  EXPEDITER,  THE 
SPECIALIST  EXPEDITER 
AND  THE  PRODUCTION 
SUPERINTENDENT 


DEBRIEFER  LOGS  ON 
MIW.  THE  APG 
EXPEDITER,  SPECIALIST 
EXPEDITER  AND  THE 
PRODUCTION 
SUPERINTENDENT  LOG 
ON  PMAs 


THE  DEBRIEFER  DEBRIEFS 
A  SORTIE  ,  IDENTIFYING 
DISCREPANT  SUBSYSTEM(s) 
ON  THE  CAPABILITY  CODE 
SCREEN 


THE  DEBRIEFER  OPENS  WORK 
ORDER(s)  ON  THE  SUBSYSTEM(s) 
INDICATED  ON  THE  CAPABILITY 
CODE  SCREEN  (OR  BY  THE  PILOT) 


IF  WORK  ORDER  ETIC  EXCEEDS 
A/C  ETIC,THE  DEBRIEFER  SEES 
DIALOG  BOX  AND  CAN  CHANGE 
OR  APPROVE  ETIC  FOR  THAT  JCN 


IF  DISCREPANCY  IS  A  POSSIBLE 
REPEAT  OR  RECUR, THE 
DEBRIEFER  SEES  DIALOG  BOX 
AND  MAKES  DETERMINATION 


ADDITIONAL  WORK  ORDERS? 


SUPPORT  SECTION  PREPARES 
THE  CARTRIDGE(S  )  FOR  THE 
DISCREPANCY(IES)  REPORTED 


TECHNICIAN  DRAWS  PMA  AND 
BEGINS  TO  TROUBLESHOOT 
DISCREPANCY 


"TROUBLESHOOTING  STARTED" 
MESSAGE  SENT  _ 


APG  EXPEDITER  RECEIVES 
MESSAGE 


TECHNICIAN  CONTINUES 
TROUBLESHOOTING  _ 


TECHNICIAN  PERFORMS 
DIAGNOSTICS,  IDENTIFIES 
PROBLEM,  ORDERS  NEW  PART, 
GETS  PRO  SUPER  APPROVAL, 
RECEIVES  RESPONSE  FROM 
CAMS/SBSS,  REMOVES  BAD  PART, 
INSTALLS  NEW  PART,  AND  DOES  OP 
CHECK  TO  VERIFY  DISCREPANCY 
CORRECTED 


THE  DEBRIEFER  VERIFIES  SORTIE 
RECAP,  AS  DISPLAYED,  THEN  PRINTS 
IT  OUT 


"DEBRIEF  COMPLETE"  MESSAGE  SENT 


APG  EXPEDITER  RECEIVES  "DEBRIEF 
COMPLETE"  MESSAGE 


"OPEN  WORK  ORDER"  MESSAGE  SENT 


APG  EXPEDITER,  SPECIALIST 
EXPEDITER,  PRODUCTION 
SUPERINTENDENT,  AND  MOC  RECEIVE 
"OPEN  WORK  ORDER"  MESSAGES 


SPECIALIST  EXPEDITER  ASSIGNS 
TECHNICIAN  TO  WORK  ORDER 


APG  EXPEDITER  VERIFIES  STATUS 


"A/C  STATUS  UPDATE"  MESSAGE  SENT 


PRODUCTION  SUPERINTENDENT 
RECEIVES  "A/C  STATUS  UPDATE" 
MESSAGE 


DEBRIEFER  LOGS  OFF  MIW 


TECHNICIAN  CLOSES  WORK  ORDER 


IF  TECHNICIAN  NOT  CERTIFIED  TO  CLEAR 
RED  X,  HE  PRESSES  ASSIST  (F2)  FUNCTION 
KEY  TO  SEND  ASSIST  MESSAGE 


APG  EXPEDITER  RECEIVES  MESSAGE 
AND  CLEARS  RED  X  AT  TECH'S  PMA _ 


"CLOSE  WORK  ORDER"  MESSAGE  SENT 


APG  EXPEDITER  RECEIVES  MESSAGE 
_ AND  UPDATES  A/C  STATUS _ 

"A/C  STATUS  UPDATE"  MESSAGE  SENT 

PRODUCTION  SUPERINTENDENT  RECEIVES 
"A/C  STATUS  UPDATE"  MESSAGE 

TECHNICIAN  SHUTS  DOWN  THE  PMA  AND 
REMOVES  THE  CARTRIDGE  FOR  DATA 
EXTRACTION 


Figure  1 1 .  End-to-End  Demonstration  Functional  Flow 


53 


to  respond  to  that  request.  The  scenarios  were  designed  to  overlap  so  that  an  action  by  one 
participant  might  require  another  participant  to  take  action.  For  example,  the  maintenance 
debriefer  created  the  work  order  to  which  the  specialist  expediter  responded. 

Four  personnel,  when  available,  were  tested  in  each  session:  an  APG  expediter,  a 
specialist  expediter,  a  production  superintendent,  and  a  maintenance  debriefer.  They  were  first 
given  an  introduction  to  IMIS  and  their  role  in  the  demonstration  was  explained;  the  group  was 
then  split  up.  Next,  each  subject  was  assigned  a  trainer  who  taught  him  or  her  the  basics  of  using 
IMIS  and  how  IMIS  supports  his  or  her  particular  job. 

After  being  trained,  each  subject  followed  the  scenario  designed  to  exercise  the  IMIS 
functions  relevant  to  his  or  her  job.  The  exercises  required  the  subjects  to  deal  with  the  messages 
previously  loaded  on  the  PMA  cartridge.  They  were  also  told  to  expect  new  messages  via  RF 
while  they  were  going  through  the  scenario.  After  the  scenario  was  completed,  the  subjects  were 
allowed  to  experiment  on  their  own  and  to  try  other  features  of  IMIS,  with  the  assistance  of  the 
trainer. 


When  the  subjects  finished  the  scenario,  they  then  completed  two  questionnaires  (to  elicit 
their  reaction  to  various  IMIS  features  and  characteristics)  and  a  workload  assessment  instrument 
(the  National  Aeronautics  and  Space  Administration  (NASA)  Task  Load  Index  (TLX)).  The  first 
questionnaire  was  a  lengthy  set  of  subjective  questions  about  IMIS  in  general,  which  were 
presented  by  the  computer;  answers,  on  a  sliding  scale,  were  easily  marked  with  a  mouse  or 
pointing  device  by  the  participant.  The  NASA  TLX  is  a  method  of  collecting  information  on 
individual  maintenance  segments  (such  as  troubleshooting,  debriefing,  scheduling,  and  so  forth) 
of  the  IMIS  demonstration.  After  each  segment,  the  user  was  presented  with  a  set  of  questions  to 
determine  the  amount  of  workload  he  or  she  experienced  with  that  segment.  The  results  were 
automatically  tabulated  at  the  end  of  each  set  to  determine  which  segments  cause  the  most 
workload  stress. 


Finally,  the  suitability  of  the  PMA  for  supporting  maintenance  management  activities  on 
the  flightline  was  evaluated  by  installing  the  PMA  in  an  expediter  vehicle  and  in  the  golf  cart 
used  by  the  production  superintendent.  A  limited  evaluation  of  the  suitability  of  the  PMA  in  the 
expediter  truck  was  conducted  by  observing  the  ease  and  convenience  of  its  use.  The 
effectiveness  of  the  PMA  RF  communications  was  evaluated  by  installing  it  in  a  vehicle  and 
transmitting  work  order  opening  and  closing  actions  from  various  distances.  In  addition,  it  was 
tested  by  installing  it  in  an  expediter  vehicle  and  transmitting  messages  from  the  flightline  as  the 
expediter  was  performing  his  duties. 


Fault  Isolation  Test 

The  Fault  Isolation  Test  was  conducted  at  Luke  AFB,  AZ  during  July  and  August  1994 
using  maintenance  people  from  the  310  FS.  The  Fault  Isolation  Test  evaluated  the  ability  of  the 
demonstration  system  to  support  on-aircraft  fault  isolation  and  repair  tasks.  The  Fault  Isolation 
Test  is  fully  documented  in  separate  Armstrong  Laboratory  reports  (AL/HR-TR-1 995-0033  and 
AL/HR-TR- 1995-0034). 
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Objectives 


The  objectives  of  the  Field  Test  were  as  follows: 

a.  To  demonstrate  that  use  of  the  IMIS  can  significantly  improve  troubleshooting 
performance  of  technicians  by  reducing  the  time  required  to  return  an  aircraft  to  service, 
spare  parts  consumption,  the  number  of  serious  errors  made  by  maintenance  technicians, 
the  time  to  order  parts,  and  the  time  to  complete  work  order  close-out  and  documentation 
procedures. 

b.  To  demonstrate  that  APG  technicians  using  IMIS  are  able  to  perform  troubleshooting 
tasks  on  F-16  avionics  subsystems  at  least  as  effectively  as  specialists  using  paper  TOs 
and  to  collect  data  for  use  in  evaluating  the  cost  benefits  of  the  IMIS. 

c.  Compare  the  performance  of  specialists  and  non-specialist  technicians  (APG  technicians) 
using  IMIS  with  their  performance  using  paper  TOs.  To  ensure  an  accurate  comparison, 
it  was  essential  that  the  technicians’  performance  be  measured  under  comparable 
conditions.  Thus,  it  was  necessary  to  measure  the  performance  of  technicians  engaged  in 
very  similar  tasks  under  very  similar  conditions— preferably  doing  the  same  tasks  under 
identical  conditions.  To  ensure  the  required  similarity  of  tasks  and  data  collection 
conditions,  an  experimental  approach  was  adopted. 


Methodology 

An  experiment  was  conducted  in  which  avionics  specialists  and  APG  technicians  each 
performed  12  troubleshooting  tasks:  six  using  IMIS  and  six  using  paper  TOs.  Twelve  avionics 
specialists  and  12  non-specialists  (airplane  general  [APG]  technicians)  performed  12  fault 
isolation  problems  on  three  F-16  subsystems:  fire  control  radar  (FCR),  head-up  display  (HUD), 
and  inertial  navigation  system  (INS).  Half  the  problems  were  performed  using  the  current  paper- 
based  technical  orders  TOs  and  part-ordering  and  documentation  procedures.  The  APG 
technicians  were  included  in  the  study  to  determine  if  the  use  of  IMIS  would  enable  non¬ 
specialist  technicians,  with  little  or  no  training  on  a  specific  aircraft  subsystem,  to  isolate  and 
repair  faults  in  that  system  at  least  as  effectively  as  specialists,  with  specific  experience  and 
training  on  the  system,  using  paper  TOs. 

The  technicians  were  closely  observed  as  they  completed  each  task.  A  data  collector  timed 
the  technicians  performance  and  recorded  data  on  problem  completion/failure,  errors  made,  and 
helps  given.'  To  successfully  complete  a  problem,  the  technician  was  required  to  verify  that  the 


’  Helps  were  given  in  selected  situations,  when  requested  by  the  technician.  Helps  for  specialists 
primarily  were  limited  to  questions  on  the  use  of  IMIS.  A  more  liberal  policy  was  folloiyed  with 
the  APG  technicians  because  they  were  unfamiliar  with  the  test-bed  systems.  APG  technicims 
often  required  help  in  locating  components  and  using  the  TOs.  Frequently,  the  helps  were  little 
more  than  a  hint  (e.g.,  remember  what  you  were  taught  in  training). 
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reported  malfunction  existed  in  the  aircraft,  identify  the  faulty  component,  identify  the  required 
repair,  order  any  required  part,  identify  the  checks  required  to  verify  that  the  repair  returned  the 
system  to  a  fully  operational  condition,  and  complete  work  order  close-out  documentation. 

Actual  repairs  were  not  made,  to  reduce  the  risk  of  damaging  the  aircraft.  Standard  times 
were  used  to  account  for  the  times  required  to  remove  and  replace  parts  and  for  the  final  system 
health.  Also,  standard  times  were  used  to  account  for  the  time  to  submit  part  orders  and  enter 
close-out  data  into  CAMS  under  the  paper  TO  condition.  The  use  of  standard  times  was 
necessary  because  there  was  no  way  to  complete  these  tasks  under  the  paper  TO  condition 
without  interfering  with  squadron  operations. 

After  completing  the  assigned  problems  using  IMIS,  the  technicians  completed  an 
automated  questionnaire  designed  to  evaluate  various  features  or  qualities  of  IMIS  (e.g., 
readability  of  the  display).  After  they  had  completed  all  their  tests,  they  completed  an  open- 
ended  questionnaire  which  asked  them  what  they  liked  about  IMIS,  what  they  did  not  like,  and 
how  IMIS  could  be  improved. 
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ACRONYMS 


A/C 

Aircraft 

ACC 

Air  Combat  Command 

AFB 

Air  Force  Base 

APR 

Air  Force  Regulation 

AFSC 

Air  Force  Specialty  Code 

AIMS 

Advanced  Tactical  Fighter  Integrated  Maintenance  System 

AIP 

Aircraft  Interface  Panel 

AL/HRG 

Armstrong  Laboratory  Logistics  Research  Division 

APG 

Airplane  General 

API 

Application  Programming  Interface 

ASA 

Applied  Science  Associates,  Inc. 

ATF 

Advanced  Tactical  Fighter 

BCS 

Baseline  Comparison  System 

BIT 

Built-In-Test 

CA 

Control  Architecture 

CALS 

Computer-Aided  Acquisition  and  Logistics  System 

CAMS 

Core  Automated  Maintenance  System 

CASE 

Computer-Aided  Software  Engineering 

CCA 

Circuit  Card  Assembly 

CD  ROM 

Compact  Disk  Read-Only  Memory 

CDM 

Content  Data  Model 

CDR 

Critical  Design  Review 

CDRL 

Contract  Data  Requirements  List 

CLSA 

Computer  Logics  Synchronous  Adaptor 

CND 

Can  Not  Duplicate 

COTS 

Commercial  Off-The-Shelf 

CPU 

Central  Processing  Unit 

CRT 

Cathode  Ray  Tube 

CSA 

Computer  Systems  Architecture 

CSCI 

Computer  Software  Configuration  Item 

DC 

Direct  Current 

DCM 

Deputy  Commander  for  Maintenance 

DEMO 

Demonstration 

DEPR  RET 

Depress  Reticle 

DM 

Diagnostics  Module 

DR 

Discrepancy  Report 

DTC 

Data  Transfer  Cartridge 

DVAL 

Data  Link  Vulnerability  Assessment 

EDM 

External  Data  Management 

EL 

Electroluminescent 

EMC 

Electromagnetic  Compatibility 

ETIC 

Estimated  Time  In  Commission 
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EU 

FCC 

FCR 

FI 

FRG 

FRM 

GAC 

GB 

HCO 

HEMP 

HESAR 

HSI 

HUD 

Hz 

I-Level 

I/F 

lA 

ICAM 

ID 

IDD 

IDE 

IDEF 

IMIS 

IMIS-DM 

IMISA 

INS 

IPB 

IRS 

JCN 

LAN 

LCD 

LED 

LFWC 

LRU 

LSA 

MASA 

MB 

MDB 

MDC 

MESL 

MFL 

MHz 

MIDAS 

MIL-STD 

MIW 


Electronic  Unit 
Fire  Control  Computer 
Fire  Control  Radar 
Fault  Isolation 

Federal  Republic  of  Germany 
Fault  Reporting  Manual 
General  Avionics  Computer 
Gigabyte 

High  Concurrency  Object 

High-Altitude  Electromagnetic  Pulse 

Human  Engineering  System  Analysis  Report 

Horizontal  Situation  Indicator 

Head-Up  Display 

Hertz 

Intermediate  Level 
Interface 

Information  Architecture 

Integrated  Computer-Aided  Manufacturing 

Identification 

Interface  Design  Document 

Intelligent  Drive  Electronics 

ICAM  Definition  System 

Integrated  Maintenance  Information  System 

IMIS  Diagnostic  Module 

IMIS  Architecture 

Inertial  Navigation  Set 

Illustrated  Parts  Breakdown 

Interface  Requirements  Specification 

Job  Control  Number 

Local  Area  Network 

Liquid  Crystal  Display 

Light  Emitting  Diode 

Lockheed  Fort  Worth  Company 

Line  Replaceable  Unit 

Logistics  Support  Analysis 

Modular  Avionics  Systems  Architecture 

Megabyte 

Maintenance  Data  Base 
Maintenance  Data  Collection 
Minimum  Essential  Subsystem  List 
Maintenance  Fault  List 
Megahertz 

Maintenance  Integrated  Data  Access  System 
Military  Standard 

Maintenance  Information  Workstation 
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MML 

Memory  Module  Loader 

MOC 

Maintenance  Operations  Center 

MRP 

Maintenance  Review  Panel 

MTBF 

Mean  Time  Between  Failures 

NASA 

National  Aeronautics  and  Space  Administration 

NCI 

NCI  Information  Systems,  Inc. 

NCVA 

Network  Communications  Vulnerability  Assessment 

NiCad 

Nickel-Cadmium 

0-Level 

Organizational  Level 

OCD 

Operational  Concept  Document 

01 

Object  Interface 

PIDS 

Prime  Item  Development  Specification 

PIPFS 

Prime  Item  Product  Fabrication  Specification 

PMA 

Portable  Maintenance  Aid 

QRL 

Quick  Reference  List 

R&D 

Research  and  Development 

RAM 

Random  Access  Memory 

RF 

Radio  Frequency 

RS 

Radio  Standard 

RTOK 

Retest  OK 

SBLC 

Standard  Base  Level  Computer 

SBSS 

Standard  Base  Supply  System 

SCO 

Santa  Cruz  Operation 

SCSI 

Small  Computer  System  Interface 

SCT 

Systems  Control  Technology,  Inc. 

SDD 

Software  Design  Document 

SEA 

Systems  Engineering  Analysis 

SPO 

System  Program  Office 

SQL 

Structured  Query  Language 

SRS 

Software  Requirements  Specification 

SSC 

Standard  Systems  Center 

sss 

System/Segment  Specification 

TAC 

Tactical  Air  Command 

TLX 

Task  Load  Index 

TO 

Technical  Order 

TO  Present 

TO  Presentation 

UI 

User  Interface 

UIB 

User  Interface  Builder 

USAFE 

United  States  Air  Forces  -  Europe 

VGA 

Video  Graphics  Array 

WCE 

Work  Center  Event 

wuc 

Work  Unit  Code 
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